"intermediate" PRNG

Question

Two popular example dynamical systems for PRNG are

• LFSRs, basically the orbit $(x^ks)_{k>0}$ for some non-zero seed $s$ and (primitive) $x$ in $GF(2^n)^{\times}$
• CTR_DRBG, say with AES128 and 256-bit seed covering the key and initial counter block (i.e. $N+2$ AES encryptions, $N$ for output and one each for updating the key and ICB).

But what about something in between? Something more efficient than "standard" CSPRNG but with better cryptographic properties than LFSRs? One could write down ad hoc constructions all day, but is there anything "good" and well-studied? My application would be high-volume hardware PRNG, so something made from small parallelizable units would be nice.

---

In an attempt to give one possible answer to the question, how about some hybrid approach with two pieces:

• Smaller, slower crypto blocks, periodically reseeded (e.g. three instances of AES-128 encryption in counter mode, one to update the key for all instances, one to update an ICB for plaintext to the instances, and one to produce 128 bits of pseudorandom every X cycles).
• A good statistical PRNG seeded by the "crypto" portion, reseeded every X cycles.

The "statistical" part may not have great "cryptographic" properties in between reseedings, but it is reseeded often. The goal then would be to find a "good" statistical portion, something smaller than using a purely "cryptographic" solution (e.g. $N+2$ parallel pipelined AES-128 instances to produce $128N$ pseudorandom bits/cycle).

Answer 1

If you assume that the RNG state remains secret, then the security properties of a PRNG are exactly the same as a stream cipher: it must be unfeasible to predict the value of a particular bit of the output, even knowing the rest of the output. So there are no intermediates between LFSR and cryptographic-strength PRNG that wouldn't be as strong as common ciphers.

CSPRNG algorithms used as general-purpose cryptographic RNG have additional properties to mitigate exposure of the state. In particular, they usually have forward secrecy, ensuring that exposure of the current state does not compromise past outputs. This involves an extra one-way transformation of the state when generating output. See What does it mean for a random number generator to be cryptographically secure? for a more formal treatment.

If you don't care about forward secrecy, then you can use a stream cipher as a PRNG. Just keep in mind that if the key is exposed, perhaps through side channels, then all past and future outputs are exposed. A common way to build stream ciphers is to run a block cipher in counter mode. For example, if your hardware already has AES acceleration, AES-CTR may be a good choice for a fast and cheap PRNG. Just make sure the key doesn't leak. Counter mode, like most non-forward-secrecy algorithms, have the advantage that you can calculate values out of order, which is useful if you need to recalculate past states later (of course you need to save the seed for that).

For parallelization, let each thread have its own state. Or, in stream cipher terms, let each thread have its own key. (With a counter mode PRNG, you could have multiple threads sharing the same key and using different counter ranges, but it's harder to ensure counter value uniqueness that way, and also harder to mitigate key exposure.) Use a thread identifier as part of the derivation of the initial state, i.e. of the stream cipher key. If you need to record which RNG state was used to perform a particular calculation, record the thread identifier as well as the global seed and the counter value.