Comment by AaronFriel | Hacker News Reader

Comment by AaronFriel | Hacker News Reader

I see that several people (even in this thread, which you'd expect better of) still expressing the prevalence of incoherent and inconsistent-with-reality beliefs about /dev/random and /dev/urandom.

This quote in particular struck me as very strange.

> From: Florian Weimer <fw@deneb.enyo.de>

> To: Thorsten Glaser <tg@mirbsd.de>

> Cc: 742145@bugs.debian.org

> Subject: Re: openssl: uses only 32 bytes (256 bit) for key generation

> Date: Wed, 19 Mar 2014 21:33:10 +0100

>

> * Thorsten Glaser:

>

> >>Historically, the OpenSSL command line tools have been intended for

> >>debugging only.

> >

> > I disagree,

>

> It's what I was told by the OpenSSL developers.

>

> > Also, what do other tools (that do not invoke openssl(1)

> > unlike most of these I saw, which were shell wrappers

> > around it) do, entropy-wise?

>

> There are different choices. Some use more bits from /dev/urandom,

> some even block on /dev/random. The latter is quite problematic for

> non-interactive key generation during package isntallation.

1. I would doubt most actually block on /dev/random, but why? /dev/urandom should be Good Enough For Everyone, except in very narrow circumstances. But why isn't someone with a firm grasp of crypto setting a safe default? Why are implementers and consumers of these components making these choices of entropy size ("some use more bits") and underlying sources ("some even block..."). This is ridiculous, I don't trust the average developer to make safe choices in this respect. Why is it okay? This is incoherent. Either OpenSSL has safe defaults, or it doesn't. Leaving it up to consumers to do it correctly is giving up - and leads me to believe it's done unsafely by default.

2. The inconsistency alluded to by referring to non-interactive key generation and "some even block on" startles me. I don't know why developers think blocking on key generation is generally safer, but if they do, why are other (perhaps the same?) developers sacrificing that safety when generating keys on package installation for the sake of user experience? If /dev/random is safer, it should be used, and if not, it shouldn't be (because of the blocking issue.) The lack of guidance from crypto-savvy developers is deeply concerning.

/dev/random is not safer. It just blocks.

Numbers can't be more or less random, either both are unsafe, or both work. Both use exactly the same algorithms (on Linux) to generate numbers, and the numbers come from the same pool.

More in depth analysis: http://www.2uo.de/myths-about-urandom/

This is probably a stupid question, as I don't know much about /dev/random and /dev/urandom (and that article doesn't seems to address it fully), but I'll ask anyway: Doesn't /dev/random block only when it estimates that the entropy pool is empty, aka when it would create unsafe numbers? The article says that the estimate is likely wrong and there is still enough entropy left, but what if it's actually empty?

If this is true, then /dev/urandom might split out unsafe bits (as unlikely it is), which to me sounds like a terrible idea when creating a key or similar very importants secrets.

> If this is true, then /dev/urandom might split out unsafe bits (as unlikely it is), which to me sounds like a terrible idea when creating a key or similar very importants secrets.

CSPRNGs such as /dev/urandom use the same cryptographic primitives that symmetric ciphers (such as AES, Twofish, Salsa20, ChaCha20, etc.) use. In the unlikely event that our CSPRNGs are broken (meaning /dev/urandom outputs "unsafe bits"), our symmetric ciphers will all be broken too. Therefore there is absolutely no point in insisting on using /dev/random to generate keys that will be used with symmetric ciphers.

(That's a little hand-wavy but I hope you get the general idea.)

Please explain the mechanism behind entropy depletion.

You should read the article to answer your own question in depth. The short version is: on Linux, both /dev/random and /dev/urandom are fed from the same CSPRNG. A CSPRNG only needs to be seeded with a few bits of entropy to generate a whole stream of unpredictable numbers. After the CSPRNG is seeded (at system boot) it no longer matters that you run out of entropy.

Disclaimer: I am not a cryptographer.

I have (actually, twice. Once when it was posted sometimes ago on HN, and once now before writing the comment).

What threw me off was that part: "Still, if you insist on never handing out random numbers that are not “backed” by sufficient entropy, you might be nervous here. I'm sleeping sound because I don't care about the entropy estimate."

I was missing the fact that the CSPRNG only needs to be seeded once to be safe, and reseeding is only a "nice thing" that's not really needed. To be fair, the article cover this, I guess I just didn't understand that part really well.

I've got it now, and it actually make sense. Thanks to you, and everyone else that used some time to educate me.

No, the entropy estimator in /dev/random does not keep /dev/random from spitting out unsafe bits while allowing /dev/urandom to do that. A CSPRNG is akin to a stream cipher. The keystream of a stream cipher is as secure at it's 0th bit as it is at its 18446744073709551616th. An AES-CTR keystream doesn't "run out" of key, and /dev/urandom doesn't "run out" of entropy.

It's frustrating the the Linux random man page implies otherwise, because the idea is cryptographically nonsensical.

Randomness is not any physical entity and thus "entropy" here is just a word for data that cannot be derived from a system state. When it is not available, the attacker still has to know the seed of kernel's PRNG to be able to re-create the keys you generated in this state. To this end, she/he has to either sniff some impractically large amount of the PRNG output (and if this is possible your machine is likely already compromised), be able to set it to a given value (see above), or to know it from some prior knowledge, for instance has an image of the VM you use or knows the default value set on boot when no entropy is available whatsoever.

In other words, if the seed hasn't leaked it is easier to brute-force the key than to fit the CPRNG output that generated it.

Right from random(4):

>If you are unsure about whether you should use /dev/random or /dev/urandom, then probably you want to use the latter. As a general rule, /dev/urandom should be used for everything except long-lived GPG/SSL/SSH keys

Later:

>While some safety margin above that minimum is reasonable, as a guard against flaws in the CPRNG algorithm, no cryptographic primitive available today can hope to promise more than 256 bits of security, so if any program reads more than 256 bits (32 bytes) from the kernel random pool per invocation, or per reasonable reseed interval (not less than one minute), that should be taken as a sign that its cryptography is not skilfully implemented.

What exactly is the problem with blocking IO if you can't read faster than 32 bytes/min (or slower)?

/edit:

In your link:

>About 256 bits of entropy are enough to get computationally secure numbers for a long, long time.

I'm not a cryptology expert and therefor delegate that stuff to qualified people. But this sounds like utter bullshit. If your OpenSSL needs n bits of entropy, it does need it, and feeding it with more pseudo random numbers from that pools seems like a horrible idea. This post convinces me that /dev/random is the right thing, and not /dev/urandom, since blocking seems to be a very, very important feature. While I wouldn't trust me to get random generators right, i'd trust that blog a way less.

The man page is wrong.

http://sockpuppet.org/blog/2014/02/25/safely-generate-random...

Once you get enough entropy into your crypto-random generator you are fine for a very, very long time. They basically use the same algorithms that are used for encryption itself (AES, etc.) and are of equal strength.

That means if you can't trust to these generators then you can't trust your encryption (i.e. you are screwed anyway).

Yes, that's why I made my reply. The lack of consistency with regards to choice of /dev/random and /dev/urandom, as well as the lack of authority and safe defaults seems like a recipe for disaster.

Why is no one authoritative on cryptography setting these defaults so that determining "what programs do with OpenSSL" is so random. Why is OpenSSL leaving these choices to programmers by default?

It seems like a terrible, terrible thing that people are micro-optimizing how big their seed is, what their source is, etc. This can not be good for security.

Ahh, I must have read that backwards, I thought you were advocating use of /dev/random.

Reply on news.ycombinator.com