I am trying to understand the CTR DRBG specification in NIST SP 800-90A. It seems slightly different to a pure stream cipher in that the key and counter are reset after each generate call using the output pseudo-random bits. I understand that this is to provide backtracking resistance.

My question is, does this imply that the output bits produced by the DRBG are dependent on how the requests are 'chunked'? i.e.

$$ Generate(state, 8) || Generate(state, 12) \neq Generate(state, 12) || Generate(state, 8) $$

...or have I not understood the specification correctly.


You are correct. The $Update$ function is called after each invocation of the $Generate$ function, and this does mean that chunking affects the output. Changing both the key and the nonce of an $AES-CTR$ key stream generator to uniformly selected (pseudo) random values will, of course, make the resulting key stream uniformly independent from what it would have otherwise been.

However, it might be noted that the first $8$ bits of $Generate(state, 12)$ equals the full $8$ bits of $Generate(state, 8)$.

It should be noted that a $DRBG$ is primarily to be used as a replacement for a $TRBG$ (true random bit generator). It is not designed to be used as a stream cipher (which must support chunking) or as a key derivation function (which might support chunking). In particular, the NIST SP 800-90A specification explicitly forbids instantiating a $DRBG$ with the same state twice, which by itself makes it impossible to use it as a stream cipher or key derivation function.

  • $\begingroup$ I consider this a very inappropriate feature for a DRBG. For instance, it could make a difference if you'd consider a DES ABA key as one 16 byte value or two 8 byte values (including parity bits for this example of course). $\endgroup$ – Maarten Bodewes Nov 21 '15 at 13:33
  • 1
    $\begingroup$ I respectfully disagree. A DRBG is not meant to be used as a PRF. It is only meant to generate bits that are to be used where ideally completely random bits should be used. $\endgroup$ – Henrick Hellström Nov 21 '15 at 13:37
  • $\begingroup$ I do not say that it should be a required feature of a DRBG, it's just that it's an awkward feature in a world where PRF's (KDF's or of course XOF's) are not abundantly available in crypto API's. But yeah, RBG's - including RBG's - should be used just to generate random data. Or in other words, security developers / architects should not abuse DRBG's as PRF's, but in practice they do. The other thing is that I don't think a deterministic algorithm should be dependent on chunk size - that's counter-intuitive at best. $\endgroup$ – Maarten Bodewes Nov 21 '15 at 13:50
  • 1
    $\begingroup$ A library that implements DRBG-AES-CTR will implement AES-PRF, which can be used as a "chunkable" PRF. $\endgroup$ – Henrick Hellström Nov 21 '15 at 13:57
  • $\begingroup$ Good edit, I did of course already upvote. I would consider this answer even better if there was a description on how the state (in $ of the standard) is affected by requesting differently sized chunks. So that would be the vector V and possibly the reseed_counter of course. $\endgroup$ – Maarten Bodewes Nov 21 '15 at 13:58

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.