3
$\begingroup$

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.

Improve this question
$\endgroup$

1 Answer 1

Reset to default
4
$\begingroup$

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.

Improve this answer
$\endgroup$
5
  • $\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 ♦
    Commented Nov 21, 2015 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
    Commented Nov 21, 2015 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 ♦
    Commented Nov 21, 2015 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
    Commented Nov 21, 2015 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 $10.2.1.1 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 ♦
    Commented Nov 21, 2015 at 13:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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