On Thu, Nov 13, 2008 at 11:36:11AM -0500, Jarod Wilson wrote: > 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@xxxxxxxxxx> > > --- > > crypto/ansi_cprng.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/crypto/ansi_cprng.c b/crypto/ansi_cprng.c > index 486aa93..a7c703d 100644 > --- a/crypto/ansi_cprng.c > +++ b/crypto/ansi_cprng.c > @@ -161,7 +161,7 @@ static int _get_more_prng_bytes(struct prng_context *ctx) > /* > * Now update our DT value > */ > - for (i = 0; i < DEFAULT_BLK_SZ; i++) { > + for (i = DEFAULT_BLK_SZ - 1; i >= 0; i--) { > ctx->DT[i] += 1; > if (ctx->DT[i] != 0) > break; > > -- > Jarod Wilson > jarod@xxxxxxxxxx > > Looks good, thanks Jarod! Acked-by: Neil Horman <nhorman@xxxxxxxxxxxxx> -- /*************************************************** *Neil Horman *nhorman@xxxxxxxxxxxxx *gpg keyid: 1024D / 0x92A74FA1 *http://pgp.mit.edu ***************************************************/ -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
