09 Mar, 2015

1 commit

  • Change the RNGs to always return 0 in success case.

    This patch ensures that seqiv.c works with RNGs other than krng. seqiv
    expects that any return code other than 0 is an error. Without the
    patch, rfc4106(gcm(aes)) will not work when using a DRBG or an ANSI
    X9.31 RNG.

    Signed-off-by: Stephan Mueller
    Signed-off-by: Herbert Xu

    Stephan Mueller
     

04 Mar, 2015

2 commits

  • The DRBG code contains memset(0) calls to initialize a varaible
    that are not necessary as the variable is always overwritten by
    the processing.

    This patch increases the CTR and Hash DRBGs by about 5%.

    Signed-off-by: Stephan Mueller
    Signed-off-by: Herbert Xu

    Stephan Mueller
     
  • The CTR DRBG only encrypts one single block at a time. Thus, use the
    single block crypto API to avoid additional overhead from the block
    chaining modes.

    With the patch, the speed of the DRBG increases between 30% and 40%.

    The DRBG still passes the CTR DRBG CAVS test.

    Signed-off-by: Stephan Mueller
    Signed-off-by: Herbert Xu

    Stephan Mueller
     

05 Jan, 2015

1 commit


22 Dec, 2014

1 commit

  • This patch adds a panic if the FIPS 140-2 self test error failed.
    Note, that entire code is only executed with fips_enabled (i.e. when the
    kernel is booted with fips=1. It is therefore not executed for 99.9% of
    all user base.

    As mathematically such failure cannot occur, this panic should never be
    triggered. But to comply with NISTs current requirements, an endless
    loop must be replaced with the panic.

    When the new version of FIPS 140 will be released, this entire
    continuous self test function will be ripped out as it will not be
    needed any more.

    This patch is functionally equivalent as implemented in ansi_cprng.c and drivers/char/random.c.

    Signed-off-by: Stephan Mueller
    Signed-off-by: Herbert Xu

    Stephan Mueller
     

27 Nov, 2014

1 commit


26 Nov, 2014

1 commit


10 Nov, 2014

1 commit

  • The kernel module drbg.ko is currently not loaded automatically when a
    DRBG is requested by a consumer. This is due to missing MODULE_ALIAS
    flags for each of the implemented DRBG types.

    This patch adds aliases for each of the 22 defined DRBGs.

    Signed-off-by: Stephan Mueller
    Signed-off-by: Herbert Xu

    Stephan Mueller
     

24 Oct, 2014

1 commit

  • The DRBG internal buffer addition function is replaced with crypto_inc when
    a buffer is to be incremented by one.

    The function drbg_add_buf is moved to the CONFIG_CRYPTO_DRBG_HASH ifdef
    area as it is now only needed for the Hash DRBG.

    Signed-off-by: Stephan Mueller
    Signed-off-by: Herbert Xu

    Stephan Mueller
     

05 Sep, 2014

2 commits


26 Aug, 2014

1 commit


25 Aug, 2014

8 commits


01 Aug, 2014

1 commit


10 Jul, 2014

1 commit


08 Jul, 2014

6 commits

  • The patch corrects the security strength of the HMAC-SHA1 DRBG to 128
    bits. This strength defines the size of the seed required for the DRBG.
    Thus, the patch lowers the seeding requirement from 256 bits to 128 bits
    for HMAC-SHA1.

    Signed-off-by: Stephan Mueller
    Signed-off-by: Herbert Xu

    Stephan Mueller
     
  • The current locking approach of the DRBG tries to keep the protected
    code paths very minimal. It is therefore possible that two threads query
    one DRBG instance at the same time. When thread A requests random
    numbers, a shadow copy of the DRBG state is created upon which the
    request for A is processed. After finishing the state for A's request is
    merged back into the DRBG state. If now thread B requests random numbers
    from the same DRBG after the request for thread A is received, but
    before A's shadow state is merged back, the random numbers for B will be
    identical to the ones for A. Please note that the time window is very
    small for this scenario.

    To prevent that there is even a theoretical chance for thread A and B
    having the same DRBG state, the current time stamp is provided as
    additional information string for each new request.

    The addition of the time stamp as additional information string implies
    that now all generate functions must be capable to process a linked
    list with additional information strings instead of a scalar.

    CC: Rafael Aquini
    Signed-off-by: Stephan Mueller
    Signed-off-by: Herbert Xu

    Stephan Mueller
     
  • When the DRBG is initialized, the core is looked up using the DRBG name.
    The name that can be used for the lookup is registered in
    cra_driver_name. The cra_name value contains stdrng.

    Thus, the lookup code must use crypto_tfm_alg_driver_name to obtain the
    precise DRBG name and select the correct DRBG.

    Signed-off-by: Stephan Mueller
    Signed-off-by: Herbert Xu

    Stephan Mueller
     
  • The CTR DRBG requires the update function to be called twice when
    generating a random number. In both cases, update function must process
    the additional information string by using the DF function. As the DF
    produces the same result in both cases, we can save one invocation of
    the DF function when the first DF function result is reused.

    The result of the DF function is stored in the scratchpad storage. The
    patch ensures that the scratchpad is not cleared when we want to reuse
    the DF result. For achieving this, the CTR DRBG update function must
    know by whom and in which scenario it is called. This information is
    provided with the reseed parameter to the update function.

    Signed-off-by: Stephan Mueller
    Signed-off-by: Herbert Xu

    Stephan Mueller
     
  • The initial format strings caused warnings on several architectures. The
    updated format strings now match the variable types.

    Reported-by: kbuild test robot
    Reported-by: Randy Dunlap
    CC: Joe Perches
    Signed-off-by: Stephan Mueller
    Signed-off-by: Herbert Xu

    Stephan Mueller
     
  • The structure used to construct the module description line was marked
    problematic by the sparse code analysis tool. The module line
    description now does not contain any ifdefs to prevent error reports
    from sparse.

    Reported-by: kbuild test robot
    Signed-off-by: Stephan Mueller
    Signed-off-by: Herbert Xu

    Stephan Mueller
     

04 Jul, 2014

3 commits

  • This patch removes the build-time test that ensures at least one RNG
    is set. Instead we will simply not build drbg if no options are set
    through Kconfig.

    This also fixes a typo in the name of the Kconfig option CRYTPO_DRBG
    (should be CRYPTO_DRBG).

    Signed-off-by: Herbert Xu

    Herbert Xu
     
  • The DRBG-style linked list to manage input data that is fed into the
    cipher invocations is replaced with the kernel linked list
    implementation.

    The change is transparent to users of the interfaces offered by the
    DRBG. Therefore, no changes to the testmgr code is needed.

    Reported-by: kbuild test robot
    Signed-off-by: Stephan Mueller
    Signed-off-by: Herbert Xu

    Stephan Mueller
     
  • For the CTR DRBG, the drbg_state->scratchpad temp buffer (i.e. the
    memory location immediately before the drbg_state->tfm variable
    is the buffer that the BCC function operates on. BCC operates
    blockwise. Making the temp buffer drbg_statelen(drbg) in size is
    sufficient when the DRBG state length is a multiple of the block
    size. For AES192 this is not the case and the length for temp is
    insufficient (yes, that also means for such ciphers, the final
    output of all BCC rounds are truncated before used to update the
    state of the DRBG!!).

    The patch enlarges the temp buffer from drbg_statelen to
    drbg_statelen + drbg_blocklen to have sufficient space.

    Reported-by: Fengguang Wu
    Signed-off-by: Stephan Mueller
    Signed-off-by: Herbert Xu

    Stephan Mueller
     

26 Jun, 2014

1 commit


20 Jun, 2014

1 commit

  • This is a clean-room implementation of the DRBG defined in SP800-90A.
    All three viable DRBGs defined in the standard are implemented:

    * HMAC: This is the leanest DRBG and compiled per default
    * Hash: The more complex DRBG can be enabled at compile time
    * CTR: The most complex DRBG can also be enabled at compile time

    The DRBG implementation offers the following:

    * All three DRBG types are implemented with a derivation function.
    * All DRBG types are available with and without prediction resistance.
    * All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available for
    the HMAC and Hash DRBGs.
    * All AES types of AES-128, AES-192 and AES-256 are available for the
    CTR DRBG.
    * A self test is implemented with drbg_healthcheck().
    * The FIPS 140-2 continuous self test is implemented.

    Signed-off-by: Stephan Mueller
    Signed-off-by: Herbert Xu

    Stephan Mueller