8 ms·
I prefer to trust the NSA on these matters. They end up saying much of what the author has written, but they make it clear why you want to use one vs the other
by msm23 11y ago
I prefer to trust the NSA on these matters. They end up saying much of what the author has written, but they make it clear why you want to use one vs the other.
The excerpt below is from
https://www.nsa.gov/ia/_files/factsheets/I43V_Slick_Sheets/Slicksheet_RNG_IntroForAppDev.pdf https://www.nsa.gov/ia/_files/factsheets/I43V_Slick_Sheets/S... (which in turn also references
https://www.nsa.gov/ia/_files/factsheets/I43V_Slick_Sheets/Slicksheet_RNG_IntroForOpSysDev.pdf https://www.nsa.gov/ia/_files/factsheets/I43V_Slick_Sheets/S... )
Unix-like Platforms (e.g. Linux, Android, and Mac OS X):
Application developers should use the fread function to read random bytes from /dev/random for cryptographic RNG services.
Because /dev/random is a blocking device, /dev/random may cause unacceptable delays, in which case application developers may prefer to implement a DRBG using /dev/random as a conditioned seed.
Application developers should use the “Random Number Generators: Introduction for Operating System Developers” guidance in developing this solution. If /dev/random
still produces unacceptable delays, developers should use /dev/urandom which is a non-blocking device, but only with a number of additional assurances:
- The entropy pool used by /dev/urandom must be
saved between reboots.
- The Linux operating system must have estimated that the entropy pool contained the appropriate security strength entropy at some point before calling /dev/urandom. The current pool estimate can be read from /proc/sys/kernel/random/entropy_avail.
At most 2^80 bytes may be read from /dev/urandom before the developer must ensure that new entropy was added to the pool.
- wfleming 11y agoMaybe I'm just tired & not able to detect sarcasm right now, but isn't 2^80 bytes more bytes than are currently stored in the world? That's on the order of 10^24, which is something like 1 million exabytes, which is a million squared terabytes, right?
- raverbashing 11y agoNo, it's called being safe And I wouldn't put it past them to have an attack (at least theorectical) that exploits this
- viraptor 11y agoThere's safe and there's FUD. Nobody will read 2^80 bytes from urandom. You'll literally run out of time before that. It would take around 1,782,051,134 years to do on my system. So if they write that there's a vulnerability after reading 2^80 bytes - that's great! We're secure. If they write that you must ensure to do something after 2^80 bytes - that's complete bullshit.
- raverbashing 11y agoYes, reading 2^80 bytes for a practical attac is impossible today (and also for the near future) However, remember when attacks to 3DES, MD5 were only theoretical? Also, you may not even need to read 2^80 bytes, there might be a (future) vulnerability that allows you to shortcut this.
- johncolanduoni 11y agoThe difference is that weaknesses were found in 3DES and MD5. Increasing computing power was not the main factor. "Only" being able to produce 2^80 random bytes is a known and expected limitation. Sure, the CSPRNG could in theory be found to have a weakness, but that has nothing to do with the 2^80 bytes and the same could be said for virtually any cryptographic algorithm.
- tptacek 11y agoWhat weaknesses in 3DES are you thinking about that yield practical attacks?
- johncolanduoni 11y agoI am not arguing that there are; that was the parent comment. However, while the 3DES weaknesses don't yield practical attacks now, they still reduce the effective key length. My point was not that 3DES is different in that it is exploitable, but that it is different from the 2^80 limit in that the CSPRNG in that the later is not a result of a mistake in the algorithm's design but instead an expected feature. Just like the fact that any fixed-size key symmetric cipher is "limited" by that key size. Now, if someone found a lower limit based on exploiting some weakness in the random number generation, the analogy with 3DES and MD5 would make more sense.
- mfukar 11y agoThe amount of digitally stored information in the world as of May 2009 [1] is in the order of 2^71. There's no way a single process in a Linux distro will live long enough to read 2^80 bytes for the foreseeable future. [1] http://www.theguardian.com/business/2009/may/18/digital-content-expansion http://www.theguardian.com/business/2009/may/18/digital-cont...
- nshepperd 11y agoIs the joke that this is awful advice? (Except for saving the entropy pool between reboots, which can be useful, afaik.)
- viraptor 11y ago> in which case application developers may prefer to implement a DRBG using /dev/random as a conditioned seed. Wait, what? dev/urandom is a DRBG seeded the same way dev/random is. This doesn't seem to make sense.
- sago 11y agoNods You're very unlikely to be continually reseeding your own DBRG with new entropy, so it will be less secure than /dev/urandom, which is. Suspiciously bad advice, there, from what I can see.
- viraptor 11y agoJust as a random counter-example, Openssl does use that method. But it actually seeds from urandom, rather than random... And fails when forking/threading by default. :( But yes, that's not common. (more info: http://wiki.openssl.org/index.php/Random_Numbers http://wiki.openssl.org/index.php/Random_Numbers)
- ben_bai 11y ago> application developers may prefer to implement a DRBG using /dev/random as a conditioned seed No. Doing random in userland is just wrong. If your program has access to /dev/urandom, use it. If not, use arc4random(). > “Random Number Generators: Introduction for Operating System Developers” Or look how OpenBSD does it. (getentropy(), arc4random(), the subsystem) > The entropy pool used by /dev/urandom must be saved between reboots. OpenBSD does this, and more. The bootloader basically seeds the kernel with old entropy from before the reboot.
- geofft 11y ago> - The entropy pool used by /dev/urandom must be saved between reboots. Every single Linux distro does this.