22 Apr, 2015

2 commits


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
     

13 Jan, 2015

1 commit

  • Commit 5d26a105b5a7 ("crypto: prefix module autoloading with "crypto-"")
    changed the automatic module loading when requesting crypto algorithms
    to prefix all module requests with "crypto-". This requires all crypto
    modules to have a crypto specific module alias even if their file name
    would otherwise match the requested crypto algorithm.

    Even though commit 5d26a105b5a7 added those aliases for a vast amount of
    modules, it was missing a few. Add the required MODULE_ALIAS_CRYPTO
    annotations to those files to make them get loaded automatically, again.
    This fixes, e.g., requesting 'ecb(blowfish-generic)', which used to work
    with kernels v3.18 and below.

    Also change MODULE_ALIAS() lines to MODULE_ALIAS_CRYPTO(). The former
    won't work for crypto modules any more.

    Fixes: 5d26a105b5a7 ("crypto: prefix module autoloading with "crypto-"")
    Cc: Kees Cook
    Signed-off-by: Mathias Krause
    Signed-off-by: Herbert Xu

    Mathias Krause
     

24 Nov, 2014

1 commit


24 Sep, 2013

1 commit

  • Stephan Mueller reported to me recently a error in random number generation in
    the ansi cprng. If several small requests are made that are less than the
    instances block size, the remainder for loop code doesn't increment
    rand_data_valid in the last iteration, meaning that the last bytes in the
    rand_data buffer gets reused on the subsequent smaller-than-a-block request for
    random data.

    The fix is pretty easy, just re-code the for loop to make sure that
    rand_data_valid gets incremented appropriately

    Signed-off-by: Neil Horman
    Reported-by: Stephan Mueller
    CC: Stephan Mueller
    CC: Petr Matousek
    CC: Herbert Xu
    CC: "David S. Miller"
    Signed-off-by: Herbert Xu

    Neil Horman
     

01 Aug, 2012

1 commit


09 Nov, 2011

1 commit

  • Apparently, NIST is tightening up its requirements for FIPS validation
    with respect to RNGs. Its always been required that in fips mode, the
    ansi cprng not be fed key and seed material that was identical, but
    they're now interpreting FIPS 140-2, section AS07.09 as requiring that
    the implementation itself must enforce the requirement. Easy fix, we
    just do a memcmp of key and seed in fips_cprng_reset and call it a day.

    v2: Per Neil's advice, ensure slen is sufficiently long before we
    compare key and seed to avoid looking at potentially unallocated mem.

    CC: Stephan Mueller
    CC: Steve Grubb
    Signed-off-by: Jarod Wilson
    Acked-by: Neil Horman
    Signed-off-by: Herbert Xu

    Jarod Wilson
     

31 Mar, 2011

1 commit


23 Nov, 2009

1 commit


27 Oct, 2009

1 commit


19 Oct, 2009

1 commit


29 Aug, 2009

1 commit


03 Jul, 2009

2 commits

  • As reported by Eric Sesterhenn the re-allocation of the cipher in reset leads
    to:
    |BUG: sleeping function called from invalid context at kernel/rwsem.c:21
    |in_atomic(): 1, irqs_disabled(): 0, pid: 4926, name: modprobe
    |INFO: lockdep is turned off.
    |Pid: 4926, comm: modprobe Tainted: G M 2.6.31-rc1-22297-g5298976 #24
    |Call Trace:
    | [] __might_sleep+0xf9/0x101
    | [] down_read+0x16/0x68
    | [] crypto_alg_lookup+0x16/0x34
    | [] crypto_larval_lookup+0x30/0xf9
    | [] crypto_alg_mod_lookup+0x1d/0x62
    | [] crypto_alloc_base+0x1e/0x64
    | [] reset_prng_context+0xab/0x13f
    | [] ? __spin_lock_init+0x27/0x51
    | [] cprng_init+0x2a/0x42
    | [] __crypto_alloc_tfm+0xfa/0x128
    | [] crypto_alloc_base+0x33/0x64
    | [] alg_test_cprng+0x30/0x1f4
    | [] alg_test+0x12f/0x19f
    | [] ? __alloc_pages_nodemask+0x14d/0x481
    | [] do_test+0xf9d/0x163f [tcrypt]
    | [] do_test+0x3a1/0x163f [tcrypt]
    | [] tcrypt_mod_init+0x35/0x7c [tcrypt]
    | [] _stext+0x54/0x12c
    | [] ? tcrypt_mod_init+0x0/0x7c [tcrypt]
    | [] ? up_read+0x16/0x2b
    | [] ? __blocking_notifier_call_chain+0x40/0x4c
    | [] sys_init_module+0xa9/0x1bf
    | [] sysenter_do_call+0x12/0x32

    because a spin lock is held and crypto_alloc_base() may sleep.
    There is no reason to re-allocate the cipher, the state is resetted in
    ->setkey(). This patches makes the cipher allocation a one time thing and
    moves it to init.

    Reported-by: Eric Sesterhenn
    Signed-off-by: Sebastian Andrzej Siewior
    Acked-by: Neil Horman
    Signed-off-by: Herbert Xu

    Sebastian Andrzej Siewior
     
  • The current code uses a mix of sping_lock() & spin_lock_irqsave(). This can
    lead to deadlock with the correct timming & cprng_get_random() + cprng_reset()
    sequence.
    I've converted them to bottom half locks since all three user grab just a BH
    lock so this runs probably in softirq :)

    Signed-off-by: Sebastian Andrzej Siewior
    Acked-by: Neil Horman
    Signed-off-by: Herbert Xu

    Sebastian Andrzej Siewior
     

18 Feb, 2009

2 commits

  • FIPS 140-2 specifies that all access to various cryptographic modules be
    prevented in the event that any of the provided self tests fail on the various
    implemented algorithms. We already panic when any of the test in testmgr.c
    fail when we are operating in fips mode. The continuous test in the cprng here
    was missed when that was implmented. This code simply checks for the
    fips_enabled flag if the test fails, and warns us via syslog or panics the box
    accordingly.

    Signed-off-by: Neil Horman
    Signed-off-by: Herbert Xu

    Neil Horman
     
  • Pseudo RNGs provide predictable outputs based on input parateters {key, V, DT},
    the idea behind them is that only the user should know what the inputs are.
    While its nice to have default known values for testing purposes, it seems
    dangerous to allow the use of those default values without some sort of safety
    measure in place, lest an attacker easily guess the output of the cprng. This
    patch forces the NEED_RESET flag on when allocating a cprng context, so that any
    user is forced to reseed it before use. The defaults can still be used for
    testing, but this will prevent their inadvertent use, and be more secure.

    Signed-off-by: Neil Horman
    Signed-off-by: Herbert Xu

    Neil Horman
     

25 Dec, 2008

3 commits

  • The ANSI X9.31 PRNG docs aren't particularly clear on how to increment DT,
    but empirical testing shows we're incrementing from the wrong end. A 10,000
    iteration Monte Carlo RNG test currently winds up not getting the expected
    result.

    From http://csrc.nist.gov/groups/STM/cavp/documents/rng/RNGVS.pdf :

    # CAVS 4.3
    # ANSI931 MCT
    [X9.31]
    [AES 128-Key]

    COUNT = 0
    Key = 9f5b51200bf334b5d82be8c37255c848
    DT = 6376bbe52902ba3b67c925fa701f11ac
    V = 572c8e76872647977e74fbddc49501d1
    R = 48e9bd0d06ee18fbe45790d5c3fc9b73

    Currently, we get 0dd08496c4f7178bfa70a2161a79459a after 10000 loops.

    Inverting the DT increment routine results in us obtaining the expected result
    of 48e9bd0d06ee18fbe45790d5c3fc9b73. Verified on both x86_64 and ppc64.

    Signed-off-by: Jarod Wilson
    Acked-by: Neil Horman
    Signed-off-by: Herbert Xu

    Jarod Wilson
     
  • While working with some FIPS RNGVS test vectors yesterday, I discovered a
    little bug in the way the ansi_cprng code works right now.

    For example, the following test vector (complete with expected result)
    from http://csrc.nist.gov/groups/STM/cavp/documents/rng/RNGVS.pdf ...

    Key = f3b1666d13607242ed061cabb8d46202
    DT = e6b3be782a23fa62d71d4afbb0e922fc
    V = f0000000000000000000000000000000
    R = 88dda456302423e5f69da57e7b95c73a

    ...when run through ansi_cprng, yields an incorrect R value
    of e2afe0d794120103d6e86a2b503bdfaa.

    If I load up ansi_cprng w/dbg=1 though, it was fairly obvious what was
    going wrong:

    ----8
    Acked-by: Neil Horman
    Signed-off-by: Herbert Xu

    Jarod Wilson
     
  • This is a patch that was sent to me by Jarod Wilson, marking off my
    outstanding todo to allow the ansi cprng to set/reset the DT counter value in a
    cprng instance. Currently crytpo_rng_reset accepts a seed byte array which is
    interpreted by the ansi_cprng as a {V key} tuple. This patch extends that tuple
    to now be {V key DT}, with DT an optional value during reset. This patch also
    fixes a bug we noticed in which the offset of the key area of the seed is
    started at DEFAULT_PRNG_KSZ rather than DEFAULT_BLK_SZ as it should be.

    Signed-off-by: Neil Horman
    Signed-off-by: Jarod Wilson
    Signed-off-by: Herbert Xu

    Neil Horman
     

29 Aug, 2008

1 commit

  • This patch adds a random number generator interface as well as a
    cryptographic pseudo-random number generator based on AES. It is
    meant to be used in cases where a deterministic CPRNG is required.

    One of the first applications will be as an input in the IPsec IV
    generation process.

    Signed-off-by: Neil Horman
    Signed-off-by: Herbert Xu

    Neil Horman