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?