Take the 2-minute tour ×
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

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?

share|improve this question
    
Why is it not sufficient to use the CSPRNG built into your operating system? /dev/urandom on any *nix, CryptGenRandom on Windows. –  Stephen Touset Apr 17 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. –  ingyhere Apr 17 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. –  Stephen Touset Apr 17 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. –  ingyhere Apr 18 at 4:16
    
Where is the seed for your CSPRNG supposed to come from? –  Matt Nordhoff Apr 19 at 2:49
show 3 more comments

1 Answer 1

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.

share|improve this answer
    
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. –  ingyhere Apr 17 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. –  Shawn C Apr 17 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. –  ingyhere Apr 17 at 20:08
    
Then you must use a real CSPRNG which is continuously reseeded like Fortuna. A stream cipher alone is not good enough, as it has a trivial distinguisher from a purely random stream: outputs won't repeat until the counter overflows. If you're running this on any *nix, use /dev/urandom. If on Windows, use CryptGenRandom. If on both platforms, use an if statement and pick whichever one is available. Your scenario is precisely the type where a poor technical decision like writing your own RNG can result in catastrophic financial consequences. –  Stephen Touset Apr 17 at 21:01
1  
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. –  Stephen Touset Apr 18 at 6:45
show 3 more comments

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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