crypto: ansi_cprng: fix inverted DT increment routine
PATCH 1/1 crypto: ansi_cprng: fix inverted DT increment routine
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.
Quoted 1 line
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.
---
crypto/ansi_cprng.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
crypto/ansi_cprng.c +1 -1
@@ -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 ;
Signature · 2 lines
Jarod Wilson [email protected]
Quoted 49 lines · Jarod Wilson
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 =48e9bd0d06ee18fbe45790d5c3fc9b73Currently, we get
0dd08496c4f7178bfa70a2161a79459aafter 10000 loops.Inverting the DT increment routine results in us obtaining the expected result of
48e9bd0d06ee18fbe45790d5c3fc9b73. Verified on bothx86_64and ppc64.Signed-off-by Jarod Wilson <[email protected]>---
crypto/ansi_cprng.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)crypto/ansi_cprng.c +1
-1@@ -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 ;Signature · 3 lines
-- Jarod Wilson [email protected]
Looks good, thanks Jarod!
Signature · 6 lines
/*************************************************** *Neil Horman *[email protected] *gpg keyid: 1024D / 0x92A74FA1 *http://pgp.mit.edu ***************************************************/
Herbert Xu
maintainerQuoted 19 lines · Neil Horman
Quoted 18 lines · Jarod Wilson
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
Quoted 6 lines
Quoted 6 lines
Currently, we get
0dd08496c4f7178bfa70a2161a79459aafter 10000 loops.Inverting the DT increment routine results in us obtaining the expected result of
48e9bd0d06ee18fbe45790d5c3fc9b73. Verified on bothx86_64and ppc64.Signed-off-by Jarod Wilson <[email protected]>
Patch applied. Thanks!
Signature · 4 lines
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt