# Using Stream Cipher as CSPRNG

Are there any guidelines or justification for converting a stream cipher algorithm for use as a CSPRNG?

For instance, lets say I wanted to convert one of the eStream portfolio Profile 1 (software) selections for use as a CSPRNG. What I could do is generate a really unique hash from some other algorithm and use it as the key. Then I could generate another really unique, lets say 64-bits, and use it as the initialization variable. Now, what are my options? I could continue regenerating output blocks based on the cipher's internal variables. I could try to encode an incrementing counter into the block stream and then get the output. I could regenerate a key and (iv) and get the output again (seems costly).

I read that it's generally not smart to re-use the key on multiple encodings, so that makes me think I should just keep regenerating the first output block. Is the original output block by definition an unending random stream?

• Why is it not sufficient to use the CSPRNG built into your operating system? /dev/urandom on any *nix, CryptGenRandom on Windows. Apr 17 '14 at 16:49
• Great question. That binds portability of the application to a specific version of an OS or runtime environment. This is for an app that requires a high degree of regulatory scrutiny. They also, apparently, do not like exposed public APIs. These are just the parameters I'm given for the problem. Apr 17 '14 at 20:03
• I don't understand how "they... do not like exposed public APIs". Unless you're building a language and runtime environment from scratch, you're using public APIs. If you include any of the eStream portfolio, you're using public APIs. Apr 17 '14 at 20:58
• Let's just say they have a philosophy where it comes to using publicly posted code for things that tangibly impact the flow of money, like RNGs and ciphers. We fly our own code from algorithms in reference texts. Apr 18 '14 at 4:16
• Where is the seed for your CSPRNG supposed to come from? Apr 19 '14 at 2:49

Using a stream cipher for mass generation of "random" bytes is a fairly good solution, however the risk is loosing Forward Secrecy at some point. The trick then is re-keying the cipher often enough, and having a good source of random data with which to rekey your cipher.

See Fortuna.

• Okay, but for 64- or 32-bit primitives that generally should not apply, right? Unless, I am using a really bad cipher with a very small (< 32-bit) internal state, which I am not planning. Please correct me if I am wrong. Apr 17 '14 at 15:37
• You need to be more specific about your threat model before folks can give more concrete advice. There is a big difference in just needing a few thousand pseudo-random values and needing cryptographically secure values. Apr 17 '14 at 17:22
• Thanks. The threat model is an online, publicly exposed application processing large sums of money that will be subject to frequent attempts to reverse engineer the number stream. It needs to be close to a TRBG/TRNG. HW RNG is not available. Apr 17 '14 at 20:08
• Yes, there absolutely is. Cryptography is hard, and if you believe it's a simple exercise to write secure code to a public spec, you're in for a bad time. Established companies with huge security teams like Amazon, Google, and Facebook can get details wrong. The notion that a developer with no cryptographic background working solo will do a better job is laughable. Apr 18 '14 at 6:45
• @StephenTouset The "outputs won't repeat" distinguisher is not universal for stream ciphers, I think, just for counter mode block ciphers or similar stuff. E.g. if you use a stream cipher build from a PRF in CTR mode, it will repeat just as often as expected for a true random stream. Apr 18 '14 at 13:01