linux/crypto/ansi_cprng.c

475 lines
11 KiB
C
Raw Permalink Normal View History

// SPDX-License-Identifier: GPL-2.0-or-later
/*
* PRNG: Pseudo Random Number Generator
* Based on NIST Recommended PRNG From ANSI X9.31 Appendix A.2.4 using
* AES 128 cipher
*
* (C) Neil Horman <nhorman@tuxdriver.com>
*/
#include <crypto/internal/cipher.h>
#include <crypto/internal/rng.h>
#include <linux/err.h>
#include <linux/init.h>
#include <linux/module.h>
#include <linux/moduleparam.h>
#include <linux/string.h>
#define DEFAULT_PRNG_KEY "0123456789abcdef"
#define DEFAULT_PRNG_KSZ 16
#define DEFAULT_BLK_SZ 16
#define DEFAULT_V_SEED "zaybxcwdveuftgsh"
/*
* Flags for the prng_context flags field
*/
#define PRNG_FIXED_SIZE 0x1
#define PRNG_NEED_RESET 0x2
/*
* Note: DT is our counter value
* I is our intermediate value
* V is our seed vector
* See http://csrc.nist.gov/groups/STM/cavp/documents/rng/931rngext.pdf
* for implementation details
*/
struct prng_context {
spinlock_t prng_lock;
unsigned char rand_data[DEFAULT_BLK_SZ];
unsigned char last_rand_data[DEFAULT_BLK_SZ];
unsigned char DT[DEFAULT_BLK_SZ];
unsigned char I[DEFAULT_BLK_SZ];
unsigned char V[DEFAULT_BLK_SZ];
u32 rand_data_valid;
struct crypto_cipher *tfm;
u32 flags;
};
static int dbg;
static void hexdump(char *note, unsigned char *buf, unsigned int len)
{
if (dbg) {
printk(KERN_CRIT "%s", note);
print_hex_dump(KERN_CONT, "", DUMP_PREFIX_OFFSET,
16, 1,
buf, len, false);
}
}
#define dbgprint(format, args...) do {\
if (dbg)\
printk(format, ##args);\
} while (0)
static void xor_vectors(unsigned char *in1, unsigned char *in2,
unsigned char *out, unsigned int size)
{
int i;
for (i = 0; i < size; i++)
out[i] = in1[i] ^ in2[i];
}
/*
* Returns DEFAULT_BLK_SZ bytes of random data per call
* returns 0 if generation succeeded, <0 if something went wrong
*/
static int _get_more_prng_bytes(struct prng_context *ctx, int cont_test)
{
int i;
unsigned char tmp[DEFAULT_BLK_SZ];
unsigned char *output = NULL;
dbgprint(KERN_CRIT "Calling _get_more_prng_bytes for context %p\n",
ctx);
hexdump("Input DT: ", ctx->DT, DEFAULT_BLK_SZ);
hexdump("Input I: ", ctx->I, DEFAULT_BLK_SZ);
hexdump("Input V: ", ctx->V, DEFAULT_BLK_SZ);
/*
* This algorithm is a 3 stage state machine
*/
for (i = 0; i < 3; i++) {
switch (i) {
case 0:
/*
* Start by encrypting the counter value
* This gives us an intermediate value I
*/
memcpy(tmp, ctx->DT, DEFAULT_BLK_SZ);
output = ctx->I;
hexdump("tmp stage 0: ", tmp, DEFAULT_BLK_SZ);
break;
case 1:
/*
* Next xor I with our secret vector V
* encrypt that result to obtain our
* pseudo random data which we output
*/
xor_vectors(ctx->I, ctx->V, tmp, DEFAULT_BLK_SZ);
hexdump("tmp stage 1: ", tmp, DEFAULT_BLK_SZ);
output = ctx->rand_data;
break;
case 2:
/*
* First check that we didn't produce the same
* random data that we did last time around through this
*/
if (!memcmp(ctx->rand_data, ctx->last_rand_data,
DEFAULT_BLK_SZ)) {
if (cont_test) {
panic("cprng %p Failed repetition check!\n",
ctx);
}
printk(KERN_ERR
"ctx %p Failed repetition check!\n",
ctx);
ctx->flags |= PRNG_NEED_RESET;
return -EINVAL;
}
memcpy(ctx->last_rand_data, ctx->rand_data,
DEFAULT_BLK_SZ);
/*
* Lastly xor the random data with I
* and encrypt that to obtain a new secret vector V
*/
xor_vectors(ctx->rand_data, ctx->I, tmp,
DEFAULT_BLK_SZ);
output = ctx->V;
hexdump("tmp stage 2: ", tmp, DEFAULT_BLK_SZ);
break;
}
/* do the encryption */
crypto_cipher_encrypt_one(ctx->tfm, output, tmp);
}
/*
* Now update our DT value
*/
for (i = DEFAULT_BLK_SZ - 1; i >= 0; i--) {
ctx->DT[i] += 1;
if (ctx->DT[i] != 0)
break;
}
dbgprint("Returning new block for context %p\n", ctx);
ctx->rand_data_valid = 0;
hexdump("Output DT: ", ctx->DT, DEFAULT_BLK_SZ);
hexdump("Output I: ", ctx->I, DEFAULT_BLK_SZ);
hexdump("Output V: ", ctx->V, DEFAULT_BLK_SZ);
hexdump("New Random Data: ", ctx->rand_data, DEFAULT_BLK_SZ);
return 0;
}
/* Our exported functions */
static int get_prng_bytes(char *buf, size_t nbytes, struct prng_context *ctx,
int do_cont_test)
{
unsigned char *ptr = buf;
unsigned int byte_count = (unsigned int)nbytes;
int err;
spin_lock_bh(&ctx->prng_lock);
err = -EINVAL;
if (ctx->flags & PRNG_NEED_RESET)
goto done;
/*
* If the FIXED_SIZE flag is on, only return whole blocks of
* pseudo random data
*/
err = -EINVAL;
if (ctx->flags & PRNG_FIXED_SIZE) {
if (nbytes < DEFAULT_BLK_SZ)
goto done;
byte_count = DEFAULT_BLK_SZ;
}
/*
* Return 0 in case of success as mandated by the kernel
* crypto API interface definition.
*/
err = 0;
dbgprint(KERN_CRIT "getting %d random bytes for context %p\n",
byte_count, ctx);
remainder:
if (ctx->rand_data_valid == DEFAULT_BLK_SZ) {
if (_get_more_prng_bytes(ctx, do_cont_test) < 0) {
memset(buf, 0, nbytes);
err = -EINVAL;
goto done;
}
}
/*
crypto: ansi_cprng - Avoid incorrect extra call to _get_more_prng_bytes 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-11-13 14:03:20 +00:00
* Copy any data less than an entire block
*/
if (byte_count < DEFAULT_BLK_SZ) {
crypto: ansi_cprng - Avoid incorrect extra call to _get_more_prng_bytes 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-11-13 14:03:20 +00:00
empty_rbuf:
while (ctx->rand_data_valid < DEFAULT_BLK_SZ) {
*ptr = ctx->rand_data[ctx->rand_data_valid];
ptr++;
byte_count--;
ctx->rand_data_valid++;
if (byte_count == 0)
goto done;
}
}
/*
* Now copy whole blocks
*/
for (; byte_count >= DEFAULT_BLK_SZ; byte_count -= DEFAULT_BLK_SZ) {
crypto: ansi_cprng - Avoid incorrect extra call to _get_more_prng_bytes 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-11-13 14:03:20 +00:00
if (ctx->rand_data_valid == DEFAULT_BLK_SZ) {
if (_get_more_prng_bytes(ctx, do_cont_test) < 0) {
crypto: ansi_cprng - Avoid incorrect extra call to _get_more_prng_bytes 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-11-13 14:03:20 +00:00
memset(buf, 0, nbytes);
err = -EINVAL;
goto done;
}
}
crypto: ansi_cprng - Avoid incorrect extra call to _get_more_prng_bytes 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-11-13 14:03:20 +00:00
if (ctx->rand_data_valid > 0)
goto empty_rbuf;
memcpy(ptr, ctx->rand_data, DEFAULT_BLK_SZ);
ctx->rand_data_valid += DEFAULT_BLK_SZ;
ptr += DEFAULT_BLK_SZ;
}
/*
crypto: ansi_cprng - Avoid incorrect extra call to _get_more_prng_bytes 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-11-13 14:03:20 +00:00
* Now go back and get any remaining partial block
*/
if (byte_count)
goto remainder;
done:
spin_unlock_bh(&ctx->prng_lock);
dbgprint(KERN_CRIT "returning %d from get_prng_bytes in context %p\n",
err, ctx);
return err;
}
static void free_prng_context(struct prng_context *ctx)
{
crypto_free_cipher(ctx->tfm);
}
static int reset_prng_context(struct prng_context *ctx,
const unsigned char *key, size_t klen,
const unsigned char *V, const unsigned char *DT)
{
int ret;
const unsigned char *prng_key;
spin_lock_bh(&ctx->prng_lock);
ctx->flags |= PRNG_NEED_RESET;
prng_key = (key != NULL) ? key : (unsigned char *)DEFAULT_PRNG_KEY;
if (!key)
klen = DEFAULT_PRNG_KSZ;
if (V)
memcpy(ctx->V, V, DEFAULT_BLK_SZ);
else
memcpy(ctx->V, DEFAULT_V_SEED, DEFAULT_BLK_SZ);
if (DT)
memcpy(ctx->DT, DT, DEFAULT_BLK_SZ);
else
memset(ctx->DT, 0, DEFAULT_BLK_SZ);
memset(ctx->rand_data, 0, DEFAULT_BLK_SZ);
memset(ctx->last_rand_data, 0, DEFAULT_BLK_SZ);
ctx->rand_data_valid = DEFAULT_BLK_SZ;
ret = crypto_cipher_setkey(ctx->tfm, prng_key, klen);
if (ret) {
dbgprint(KERN_CRIT "PRNG: setkey() failed flags=%x\n",
crypto_cipher_get_flags(ctx->tfm));
goto out;
}
crypto: ansi_prng - alloc cipher just in init 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-03 04:10:47 +00:00
ret = 0;
ctx->flags &= ~PRNG_NEED_RESET;
out:
spin_unlock_bh(&ctx->prng_lock);
crypto: ansi_prng - alloc cipher just in init 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-03 04:10:47 +00:00
return ret;
}
static int cprng_init(struct crypto_tfm *tfm)
{
struct prng_context *ctx = crypto_tfm_ctx(tfm);
spin_lock_init(&ctx->prng_lock);
crypto: ansi_prng - alloc cipher just in init 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-03 04:10:47 +00:00
ctx->tfm = crypto_alloc_cipher("aes", 0, 0);
if (IS_ERR(ctx->tfm)) {
dbgprint(KERN_CRIT "Failed to alloc tfm for context %p\n",
ctx);
return PTR_ERR(ctx->tfm);
}
if (reset_prng_context(ctx, NULL, DEFAULT_PRNG_KSZ, NULL, NULL) < 0)
return -EINVAL;
/*
* after allocation, we should always force the user to reset
* so they don't inadvertently use the insecure default values
* without specifying them intentially
*/
ctx->flags |= PRNG_NEED_RESET;
return 0;
}
static void cprng_exit(struct crypto_tfm *tfm)
{
free_prng_context(crypto_tfm_ctx(tfm));
}
static int cprng_get_random(struct crypto_rng *tfm,
const u8 *src, unsigned int slen,
u8 *rdata, unsigned int dlen)
{
struct prng_context *prng = crypto_rng_ctx(tfm);
return get_prng_bytes(rdata, dlen, prng, 0);
}
/*
* This is the cprng_registered reset method the seed value is
* interpreted as the tuple { V KEY DT}
* V and KEY are required during reset, and DT is optional, detected
* as being present by testing the length of the seed
*/
static int cprng_reset(struct crypto_rng *tfm,
const u8 *seed, unsigned int slen)
{
struct prng_context *prng = crypto_rng_ctx(tfm);
const u8 *key = seed + DEFAULT_BLK_SZ;
const u8 *dt = NULL;
if (slen < DEFAULT_PRNG_KSZ + DEFAULT_BLK_SZ)
return -EINVAL;
if (slen >= (2 * DEFAULT_BLK_SZ + DEFAULT_PRNG_KSZ))
dt = key + DEFAULT_PRNG_KSZ;
reset_prng_context(prng, key, DEFAULT_PRNG_KSZ, seed, dt);
if (prng->flags & PRNG_NEED_RESET)
return -EINVAL;
return 0;
}
#ifdef CONFIG_CRYPTO_FIPS
static int fips_cprng_get_random(struct crypto_rng *tfm,
const u8 *src, unsigned int slen,
u8 *rdata, unsigned int dlen)
{
struct prng_context *prng = crypto_rng_ctx(tfm);
return get_prng_bytes(rdata, dlen, prng, 1);
}
static int fips_cprng_reset(struct crypto_rng *tfm,
const u8 *seed, unsigned int slen)
{
u8 rdata[DEFAULT_BLK_SZ];
const u8 *key = seed + DEFAULT_BLK_SZ;
int rc;
struct prng_context *prng = crypto_rng_ctx(tfm);
if (slen < DEFAULT_PRNG_KSZ + DEFAULT_BLK_SZ)
return -EINVAL;
/* fips strictly requires seed != key */
if (!memcmp(seed, key, DEFAULT_PRNG_KSZ))
return -EINVAL;
rc = cprng_reset(tfm, seed, slen);
if (!rc)
goto out;
/* this primes our continuity test */
rc = get_prng_bytes(rdata, DEFAULT_BLK_SZ, prng, 0);
prng->rand_data_valid = DEFAULT_BLK_SZ;
out:
return rc;
}
#endif
static struct rng_alg rng_algs[] = { {
.generate = cprng_get_random,
.seed = cprng_reset,
.seedsize = DEFAULT_PRNG_KSZ + 2 * DEFAULT_BLK_SZ,
.base = {
.cra_name = "stdrng",
.cra_driver_name = "ansi_cprng",
.cra_priority = 100,
.cra_ctxsize = sizeof(struct prng_context),
.cra_module = THIS_MODULE,
.cra_init = cprng_init,
.cra_exit = cprng_exit,
}
#ifdef CONFIG_CRYPTO_FIPS
}, {
.generate = fips_cprng_get_random,
.seed = fips_cprng_reset,
.seedsize = DEFAULT_PRNG_KSZ + 2 * DEFAULT_BLK_SZ,
.base = {
.cra_name = "fips(ansi_cprng)",
.cra_driver_name = "fips_ansi_cprng",
.cra_priority = 300,
.cra_ctxsize = sizeof(struct prng_context),
.cra_module = THIS_MODULE,
.cra_init = cprng_init,
.cra_exit = cprng_exit,
}
#endif
} };
/* Module initalization */
static int __init prng_mod_init(void)
{
return crypto_register_rngs(rng_algs, ARRAY_SIZE(rng_algs));
}
static void __exit prng_mod_fini(void)
{
crypto_unregister_rngs(rng_algs, ARRAY_SIZE(rng_algs));
}
MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("Software Pseudo Random Number Generator");
MODULE_AUTHOR("Neil Horman <nhorman@tuxdriver.com>");
module_param(dbg, int, 0);
MODULE_PARM_DESC(dbg, "Boolean to enable debugging (0/1 == off/on)");
subsys_initcall(prng_mod_init);
module_exit(prng_mod_fini);
MODULE_ALIAS_CRYPTO("stdrng");
MODULE_ALIAS_CRYPTO("ansi_cprng");
MODULE_IMPORT_NS(CRYPTO_INTERNAL);