[cryptography] urandom vs random
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
> 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
> 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 /
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