0
$\begingroup$

I am testing my Python implementation of NIST SP800-90A CTR_DRBG https://csrc.nist.gov/publications/detail/sp/800-90a/rev-1/final (AES-256, no df) with the CAVP test vectors (https://csrc.nist.gov/CSRC/media/Projects/Cryptographic-Algorithm-Validation-Program/documents/drbg/drbgtestvectors.zip), and have been stuck for the past couple of days.

The challenge I face is related to the CTR_DRBG_Generate function as specified in Section 10.2.1.5.1 (Generating Pseudorandom Bits When a Derivation Function is Not Used) of the above mentioned NIST SP800-90A standard.

[AES-256 no df]
[PredictionResistance = True]
[EntropyInputLen = 384]
[NonceLen = 0]
[PersonalizationStringLen = 0]
[AdditionalInputLen = 0]
[ReturnedBitsLen = 512]

COUNT = 0
EntropyInput = faf346c9c8afbc5ab6e33ce492247fac6db9a7ba4297557f587a42563ddf56c90e41c6afb56233815b74e091bac7d8e5
Nonce = 
PersonalizationString = 
** INSTANTIATE:
    Key = a9fccc320fea8ae31f80881556ef0c27a31ee7870ff73e115f348785872ccbd1
    V   = 7c21c56582c419f58ad6151fcfc1ed6b

This works, the Key and V values are correct after a call to my CTR_DRBG_Generate function.

AdditionalInput = 
EntropyInputPR = dfc111252d7146922713720ae1e348a07ae403b5238fefb4e8592f6f6cc4a61c94828db84c6faecd1502261008011f2c
** GENERATE (FIRST CALL):
    Key = 59ab2aa229c17b2ccf5b633ad905aa4396d717cd7109c4396176b445e23b54b0
    V   = 9ac50e38805dab58baf6429436e00b39

This does not work, the resulting Key and V values from my implementation are different; so my first instinct was to look for an error in the design of my CTR_DRBG_Generate function. As a side note, would you agree that the EntropyInputPR is redundant and not needed at all?

AdditionalInput = 
EntropyInputPR = 4528bac5b99c772347d44f4ece79bc811ca8ebea9483fa5f5040c02f77069dad1aec7adaa8a9a6a9ddabab045d328a90
ReturnedBits = bc013dc891db12c34ad11944805bf13dfd67ff2c23176d83f5b396b69e400042252e11816c3095421137181a5d0ee37c83a339c58d080946ca90aa437d50d9cf
** GENERATE (SECOND CALL):
    Key = 48f4632bbc79c4bde48a8588a5395afcdccc84f2a3b25b8be2715cd8f9dd8a6b
    V   = 24f485205e3baf899b8c226c2ffc73ce

As the first call to CTR_DRBG_Generate did not work, I tried to debug my design by simply emulating the second call to generate by inputting the resulting Key value from the GENERATE (FIRST CALL) (59ab2aa229c17b2ccf5b633ad905aa4396d717cd7109c4396176b445e23b54b0) and the "increment-by-one" (see Step 4.1 in 10.2.1.5.1) value of the resulting V from the GENERATE (FIRST CALL), i.e. (9ac50e38805dab58baf6429436e00b3a).

Based on my reading of the CTR_DRBG_Generate process, the first 128 bits of generated randomness should be the output of AES-ECB(Key, V) (Step 4.2). However, the AES-ECB of the above mentioned key (59ab2aa229c17b2ccf5b633ad905aa4396d717cd7109c4396176b445e23b54b0) and V (9ac50e38805dab58baf6429436e00b3a) is f237788641e684172275415827a3e87e, and not bc013dc891db12c34ad11944805bf13d which represents the first 128 bits of the "ReturnedBits" from GENERATE (SECOND CALL).

Am i misinterpreting the CTR_DRBG_Generate process or what can explain the mismatch between the test vectors and my output?

$\endgroup$
1
  • 1
    $\begingroup$ Test vectors are test vectors to satisfy. If there is a random, then the test vectors define them to be fixed so that you can see that you have a problem or not. $\endgroup$ – kelalaka May 12 at 16:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.