[cryptography] urandom vs random

ianG iang at iang.org
Sat Aug 17 08:05:05 EDT 2013

On 17/08/13 14:46 PM, Ben Laurie wrote:
> On 17 August 2013 06:01, ianG <iang at iang.org <mailto:iang at iang.org>> wrote:
>     On 17/08/13 10:57 AM, Peter Gutmann wrote:
>         Nico Williams <nico at cryptonector.com
>         <mailto:nico at cryptonector.com>> writes:
>             It might be useful to think of what a good API would be.
>         The problem isn't the API, it's the fact that you've got two
>         mutually
>         exclusive requirements, the security geeks want the (P)RNG to
>         block until
>         enough entropy is available, everyone else wants execution to
>         continue without
>         being blocked.  In other words a failure of security is
>         preferred to a failure
>         of functionality.  Until you resolve that conflict, no API
>         (re)design is going
>         to help you.
>     (not answering the posts sepcifically but) the rule of thumb I've
>     always used is this:
>     If you don't care so much about security then use the tools that are
>     provided, and suffer an occasional glitch.  Don't worry too much
>     about the glitches coz your business already told you, you don't
>     care too much about the security / randomness.  All those
>     cypherpunkian arguments can go to hell, you've got customers to care
>     for.
>     OTOH, if you care a lot, then you have to write your own.  The
>     design is now very well established.  Many sources -> mixer/pool ->
>     deterministic PRNG.  It's really not that hard, this is an intern
>     level project, folks.
>     In result, if you care enough to argue about random v. urandom then
>     you already put yourself in the second camp, and your problem is
>     solved. Just use urandom and collect some other sources yourself.
>       You no longer care.
> That's terrible advice. Implement your own crypto of any sort widely
> leads to complete fail, as we see repeatedly.

:)  Perhaps the distinction is that, if you care, when you "repeatedly 
fail" then you can repeatedly fix it.  OTOH, if you're using external 
crypto, you're up the creek without a paddle.

> Also, if there are other sources, why are they not being fed in to the
> system PRNG?

I agree in principle, but reality slaps us around a bit:

Linux and BSD can't agree on the basic definitions of urandom and 
random.  Some don't agree whether Intel's RNG is safe or not for Linux 
purposes.  Zooko & Jon don't agree whether open source is a sufficient / 
necessary proof.

And, as you say, FIPS don't agree with anyone:

 > Amusing story: FIPS 140 requires self-tests on the PRNG. There was a
 > bug in FIPS OpenSSL once where the self-test mode got stuck on and so
 > no entropy was fed into the PRNG.
 > Also, back when I was doing FIPS 140 they made me remove some of the
 > entropy feeds into the PRNG - particularly ones that protect against
 > pool duplication over forks.


More information about the cryptography mailing list