summaryrefslogtreecommitdiff
path: root/crypto/ansi_cprng.c
AgeCommit message (Collapse)AuthorFilesLines
2015-01-13crypto: add missing crypto module aliasesMathias Krause1-0/+1
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 <keescook@chromium.org> Signed-off-by: Mathias Krause <minipli@googlemail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-11-24crypto: prefix module autoloading with "crypto-"Kees Cook1-1/+1
This prefixes all crypto module loading with "crypto-" so we never run the risk of exposing module auto-loading to userspace via a crypto API, as demonstrated by Mathias Krause: https://lkml.org/lkml/2013/3/4/70 Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2013-09-24crypto: ansi_cprng - Fix off by one error in non-block size requestNeil Horman1-2/+2
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 <nhorman@tuxdriver.com> Reported-by: Stephan Mueller <stephan.mueller@atsec.com> CC: Stephan Mueller <stephan.mueller@atsec.com> CC: Petr Matousek <pmatouse@redhat.com> CC: Herbert Xu <herbert@gondor.apana.org.au> CC: "David S. Miller" <davem@davemloft.net> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2012-08-01crypto: ansi_cprng - use crypto_[un]register_algsJussi Kivilinna1-40/+23
Combine all crypto_alg to be registered and use new crypto_[un]register_algs functions. This simplifies init/exit code. Cc: Neil Horman <nhorman@tuxdriver.com> Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2011-11-09crypto: ansi_cprng - enforce key != seed in fips modeJarod Wilson1-0/+8
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 <smueller@atsec.com> CC: Steve Grubb <sgrubb@redhat.com> Signed-off-by: Jarod Wilson <jarod@redhat.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2011-03-31Fix common misspellingsLucas De Marchi1-1/+1
Fixes generated by 'codespell' and manually reviewed. Signed-off-by: Lucas De Marchi <lucas.demarchi@profusion.mobi>
2009-11-23crypto: ansi_cprng - Move FIPS functions under CONFIG_CRYPTO_FIPSJaswinder Singh Rajput1-28/+28
fips_cprng_get_random and fips_cprng_reset is used only by CONFIG_CRYPTO_FIPS. This also fixes compilation warnings: crypto/ansi_cprng.c:360: warning: ‘fips_cprng_get_random’ defined but not used crypto/ansi_cprng.c:393: warning: ‘fips_cprng_reset’ defined but not used Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2009-10-27crypto: ansi_cprng - Fix test in get_prng_bytesRoel Kluin1-3/+0
size_t nbytes cannot be less than 0 and the test was redundant. Signed-off-by: Roel Kluin <roel.kluin@gmail.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2009-10-19crypto: ansi_cprng - Add FIPS wrapperNeil Horman1-9/+70
Patch to add fips(ansi_cprng) alg, which is ansi_cprng plus a continuous test Signed-off-by: Neil Horman <nhorman@tuxdriver.com> Acked-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2009-08-29crypto: ansi_cprng - Fix module initializationSteffen Klassert1-8/+1
Return the value we got from crypto_register_alg() instead of returning 0 in any case. Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2009-07-03crypto: ansi_prng - alloc cipher just in initSebastian Andrzej Siewior1-17/+8
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: | [<c011dd93>] __might_sleep+0xf9/0x101 | [<c0777aa0>] down_read+0x16/0x68 | [<c048bf04>] crypto_alg_lookup+0x16/0x34 | [<c048bf52>] crypto_larval_lookup+0x30/0xf9 | [<c048c038>] crypto_alg_mod_lookup+0x1d/0x62 | [<c048c13e>] crypto_alloc_base+0x1e/0x64 | [<c04bf991>] reset_prng_context+0xab/0x13f | [<c04e5cfc>] ? __spin_lock_init+0x27/0x51 | [<c04bfce1>] cprng_init+0x2a/0x42 | [<c048bb4c>] __crypto_alloc_tfm+0xfa/0x128 | [<c048c153>] crypto_alloc_base+0x33/0x64 | [<c04933c9>] alg_test_cprng+0x30/0x1f4 | [<c0493329>] alg_test+0x12f/0x19f | [<c0177f1f>] ? __alloc_pages_nodemask+0x14d/0x481 | [<d09219e2>] do_test+0xf9d/0x163f [tcrypt] | [<d0920de6>] do_test+0x3a1/0x163f [tcrypt] | [<d0926035>] tcrypt_mod_init+0x35/0x7c [tcrypt] | [<c010113c>] _stext+0x54/0x12c | [<d0926000>] ? tcrypt_mod_init+0x0/0x7c [tcrypt] | [<c01398a3>] ? up_read+0x16/0x2b | [<c0139fc4>] ? __blocking_notifier_call_chain+0x40/0x4c | [<c014ee8d>] sys_init_module+0xa9/0x1bf | [<c010292b>] 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 <eric.sesterhenn@lsexperts.de> Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc> Acked-by: Neil Horman <nhorman@tuxdriver.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2009-07-03crypto: ansi_prng - Use just a BH lockSebastian Andrzej Siewior1-5/+4
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 <sebastian@breakpoint.cc> Acked-by: Neil Horman <nhorman@tuxdriver.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2009-02-18crypto: ansi_cprng - Panic on CPRNG test failure when in FIPS mode Neil Horman1-0/+6
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 <nhorman@tuxdriver.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2009-02-18crypto: ansi_cprng - Force reset on allocationNeil Horman1-1/+10
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 <nhorman@redhat.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2008-12-25crypto: ansi_cprng - fix inverted DT increment routineJarod Wilson1-1/+1
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 <jarod@redhat.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2008-12-25crypto: ansi_cprng - Avoid incorrect extra call to _get_more_prng_bytesJarod Wilson1-6/+11
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<---- getting 16 random bytes for context ffff810033fb2b10 Calling _get_more_prng_bytes for context ffff810033fb2b10 Input DT: 00000000: e6 b3 be 78 2a 23 fa 62 d7 1d 4a fb b0 e9 22 fc Input I: 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Input V: 00000000: f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 tmp stage 0: 00000000: e6 b3 be 78 2a 23 fa 62 d7 1d 4a fb b0 e9 22 fc tmp stage 1: 00000000: f4 8e cb 25 94 3e 8c 31 d6 14 cd 8a 23 f1 3f 84 tmp stage 2: 00000000: 8c 53 6f 73 a4 1a af d4 20 89 68 f4 58 64 f8 be Returning new block for context ffff810033fb2b10 Output DT: 00000000: e7 b3 be 78 2a 23 fa 62 d7 1d 4a fb b0 e9 22 fc Output I: 00000000: 04 8e cb 25 94 3e 8c 31 d6 14 cd 8a 23 f1 3f 84 Output V: 00000000: 48 89 3b 71 bc e4 00 b6 5e 21 ba 37 8a 0a d5 70 New Random Data: 00000000: 88 dd a4 56 30 24 23 e5 f6 9d a5 7e 7b 95 c7 3a Calling _get_more_prng_bytes for context ffff810033fb2b10 Input DT: 00000000: e7 b3 be 78 2a 23 fa 62 d7 1d 4a fb b0 e9 22 fc Input I: 00000000: 04 8e cb 25 94 3e 8c 31 d6 14 cd 8a 23 f1 3f 84 Input V: 00000000: 48 89 3b 71 bc e4 00 b6 5e 21 ba 37 8a 0a d5 70 tmp stage 0: 00000000: e7 b3 be 78 2a 23 fa 62 d7 1d 4a fb b0 e9 22 fc tmp stage 1: 00000000: 80 6b 3a 8c 23 ae 8f 53 be 71 4c 16 fc 13 b2 ea tmp stage 2: 00000000: 2a 4d e1 2a 0b 58 8e e6 36 b8 9c 0a 26 22 b8 30 Returning new block for context ffff810033fb2b10 Output DT: 00000000: e8 b3 be 78 2a 23 fa 62 d7 1d 4a fb b0 e9 22 fc Output I: 00000000: c8 e2 01 fd 9f 4a 8f e5 e0 50 f6 21 76 19 67 9a Output V: 00000000: ba 98 e3 75 c0 1b 81 8d 03 d6 f8 e2 0c c6 54 4b New Random Data: 00000000: e2 af e0 d7 94 12 01 03 d6 e8 6a 2b 50 3b df aa returning 16 from get_prng_bytes in context ffff810033fb2b10 ----8<---- The expected result is there, in the first "New Random Data", but we're incorrectly making a second call to _get_more_prng_bytes, due to some checks that are slightly off, which resulted in our original bytes never being returned anywhere. One approach to fixing this would be to alter some byte_count checks in get_prng_bytes, but it would mean the last DEFAULT_BLK_SZ bytes would be copied a byte at a time, rather than in a single memcpy, so a slightly more involved, equally functional, and ultimately more efficient way of fixing this was suggested to me by Neil, which I'm submitting here. All of the RNGVS ANSI X9.31 AES128 VST test vectors I've passed through ansi_cprng are now returning the expected results with this change. Signed-off-by: Jarod Wilson <jarod@redhat.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2008-12-25crypto: ansi_cprng - Allow resetting of DT valueNeil Horman1-3/+13
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 <nhorman@tuxdriver.com> Signed-off-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2008-08-29crypto: rng - RNG interface and implementationNeil Horman1-0/+417
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 <nhorman@tuxdriver.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
generated by cgit v1.2.3 (git 2.39.0) at 2024-11-17 17:16:42 +0300