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?

  • $\begingroup$ Why is it not sufficient to use the CSPRNG built into your operating system? /dev/urandom on any *nix, CryptGenRandom on Windows. $\endgroup$ – Stephen Touset Apr 17 '14 at 16:49
  • $\begingroup$ 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. $\endgroup$ – ingyhere Apr 17 '14 at 20:03
  • $\begingroup$ 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. $\endgroup$ – Stephen Touset Apr 17 '14 at 20:58
  • $\begingroup$ 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. $\endgroup$ – ingyhere Apr 18 '14 at 4:16
  • $\begingroup$ Where is the seed for your CSPRNG supposed to come from? $\endgroup$ – Matt Nordhoff 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.

| improve this answer | |
  • $\begingroup$ 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. $\endgroup$ – ingyhere Apr 17 '14 at 15:37
  • $\begingroup$ 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. $\endgroup$ – Shawn C Apr 17 '14 at 17:22
  • $\begingroup$ 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. $\endgroup$ – ingyhere Apr 17 '14 at 20:08
  • 2
    $\begingroup$ 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. $\endgroup$ – Stephen Touset Apr 18 '14 at 6:45
  • 2
    $\begingroup$ @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. $\endgroup$ – Paŭlo Ebermann Apr 18 '14 at 13:01

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.