4 ms·

/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

by 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.
- tptacek 13y ago
  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.
- mbq 13y ago
  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.
1ris 13y ago
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.
- tptacek 13y ago
  The man page is wrong. http://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/ http://sockpuppet.org/blog/2014/02/25/safely-generate-random...
- deleted 13y ago
  [deleted]
- vilda 13y ago
  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).
AaronFriel 13y ago
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.
- fleitz 13y ago
  Ahh, I must have read that backwards, I thought you were advocating use of /dev/random.

by fleitz 13y ago

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.
tptacek 13y ago
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.
mbq 13y ago
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.

1ris 13y ago

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.

tptacek 13y ago
The man page is wrong. http://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/ http://sockpuppet.org/blog/2014/02/25/safely-generate-random...
deleted 13y ago
[deleted]
vilda 13y ago
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).

AaronFriel 13y ago

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.

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