4 ms·

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 belief

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.

fleitz 13y ago
/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/ http://www.2uo.de/myths-about-urandom/
- Spittie 13y ago
  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.
  - agwa 13y ago
    > 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.)
  - kzrdude 13y ago
    Please explain the mechanism behind entropy depletion.
  - tjgq 13y ago
    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.
    - Spittie 13y ago
      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.

fleitz 13y ago

/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/ http://www.2uo.de/myths-about-urandom/

Spittie 13y ago
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.
- agwa 13y ago
  > 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.)
- kzrdude 13y ago
  Please explain the mechanism behind entropy depletion.
- tjgq 13y ago
  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.
  - Spittie 13y ago
    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.