I have been learning about block ciphers, modes of operations, and csprngs by myself for a few days and there are some things I'm unsure about.

Assuming we only talk about cryptographically secure block ciphers; can any block cipher in CTR mode be used as a CSPRNG? Or are there specifc characteristics a block cipher should have to be used as such?

Can such a CSPRNG be used to produce key material, or do I have to specifically use a key generation/derivation algorithm for that purpose?

2 Answers
2

Formally speaking the CTR mode transforms a PRF (or a PRP) into a PRG and as the PRP notion is the standard notion to model block ciphers, pretty much all secure block ciphers should yield a secure PRG when used in CTR mode.

Less formally speaking CTR mode transforms a secure block cipher into a secure stream cipher. This implies that you "encrypt a stream of zeroes" which should be properly secure as a CSPRNG because chances are that you could break the stream cipher otherwise.

Finally you'll also see CTR mode as a building block for a sophisticated CSPRNG in practice quite often, for example with CTR_DRBG (PDF) (which among other applications is used by Intel's RdRand).

Or are there specifc characteristics a block cipher should have to be
used as such?

As said above, it should behave like a PRP, that's all, but (nearly?) all secure block ciphers do just that.

Can such a CSPRNG be used to produce key material, or do I have to
specifically use a key generation/derivation algorithm for that
purpose?

Technically you could use CTR mode directly to derive keying material. However specialized CSPRNG constructions and KBKDFs exist for reason. So if you have a properly seeded CSPRNG, you can directly derive keys from that or else you want to use a KBKDF if you're basing of some shared keying material (like a DH shared secret).

These specialized algorithms usually allow for customization and have advanced usage scenarios in mind. So for example you have a static secret and a counter? You can use CTR_DRBG to turn this into a CSPRNG! Or you have a secret key and some context? You can use HKDF to derive keying material with a context label and context info!

$\begingroup$I don't want to write another answer as this one covers all the bases pretty well. I just do want to mention that the CTR_DRBG also contains methods for re-seeding and suchlike. You can retrieve data from a stream cipher pretty well, but there are no described ways of reseeding the cipher. (If you want to use the CSPRNG purely for generating a deterministic stream of data you may not want to reseed or reseed at the right time with the right seed of course, in that case you might just want to use the stream cipher)$\endgroup$
– Maarten Bodewes♦Apr 16 '17 at 12:51

There's a subtle problem with your question, which is that the term "CSPRNG" is a little bit vague. There are two common kinds of applications for (pseudo)random generators in cryptography:

Two parties need to make deterministic, reproducible choices that appear random to a third party.

One party needs to make a nondeterministic, irreproducible choices that appear random to any other party.

Situation #1 properly requires cryptographic-strength pseudorandomness (a pseudorandom generator, pseudorandom function, pseudorandom permutation); if you used a true random number generator in its place such an application would not work.

Situation #2's requirements on the other hand could be fulfilled with a true random number generator, but in practice we normally use designs that incorporate pseudorandom generators for engineering reasons. Such generators typically use a #1-type algorithm as an internal component, but provide additional security features that are inapplicable or fatal for situation #1:

Forward secrecy: ensuring that compromises of the RNG state cannot be used to backtrack to earlier outputs.

Prediction resistance: ensuring that compromises of the RNG state can only predict its future output during a limited time window. This is normally accomplished by sampling random data (e.g., keyboard timings) and scrambling the RNG's state with it.

Assuming we only talk about cryptographically secure block ciphers; can any block cipher in CTR mode be used as a CSPRNG? Or are there specific characteristics a block cipher should have to be used as such?

Any secure block cipher in CTR mode will give you a generator that's suitable for situation #1.

Can such a CSPRNG be used to produce key material, or do I have to specifically use a key generation/derivation algorithm for that purpose?

Producing master key material is situation #2; you could substitute a true random generator and the system would still work. So a block cipher in CTR mode, seeded with a random key, meets the minimal requirements but is not the best solution. You should prefer the sort of random number generators that OSes incorporate, with the additional security features.

Again, rule of thumb: would this application work just as correctly with a true random generator? In that case, you don't really want a pseudorandom generator—you want a good surrogate for a true RNG, which is allowed but not required to use pseudorandomness.

$\begingroup$Thanks for pointing out to this here layman / non infosec-professional that "proper" randomness is actually not strictly superior to "pseudo" randomness, depending on the use case. It's so obvious now that you laid it out, but I just never thought about it.$\endgroup$
– Jörg W MittagApr 14 '17 at 21:36