4
$\begingroup$

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?

Improve this question
$\endgroup$
8
  • $\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, 2014 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, 2014 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, 2014 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, 2014 at 4:16
  • $\begingroup$ Where is the seed for your CSPRNG supposed to come from? $\endgroup$
    – Matt Nordhoff
    Apr 19, 2014 at 2:49

1 Answer 1

Reset to default
4
$\begingroup$

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
$\endgroup$
8
  • $\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, 2014 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, 2014 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, 2014 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, 2014 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, 2014 at 13:01

Your Answer

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

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