[throwaway092834]

These aren't myths, they're platform guarantees. It just so happens that a few of the most common unixes (Linux, BSD) implement a very good /dev/urandom and the author is suggesting that we write non-portable software that depends on implementation details of these platforms.

There can be benefits from depending on non-portable implementation details but also significant drawbacks.

[fulafel]

There's no standard for this - Linux folks came up & implemented it first and other platforms have taken that as compatibility target. So "non-portable implementation details" is all there is, and it works fine for CSPRNG.

[throwaway092834]

You're hinting that it's not in POSIX, and this is true.

There are many standards and cross-platform interfaces defined outside of POSIX. Some explicit and top-down, some organically evolved.

The spec for /dev/*random is here, as was published in the mid-90s: http://git.kernel.org/cgit/linux/kernel/git/stable/linux-sta...

[tptacek]

No. Applications on Linux should use urandom to the exclusion of any other CSPRNG.

[bostik]

> Applications on Linux should use urandom to the exclusion of any other CSPRNG

Applications, yes. Appliances built on it - now that's more open to interpretation.

Back in 2003/2004 I was building a centrally managed security appliance system. At the time I made the hard choice that first-boot operations (such as generating long-term device keys) MUST use /dev/random. It made the initial installs take longer, but I refused to take the chance that an attacker could install and instrument a few hundred nodes and find out possible problems with entropy sources.

Once the first-boot sequence was over, applications used /dev/urandom for everything. This included the ipsec daemons. Forcing everything to /dev/random during first boot made sure that on subsequent boots there would be (for all practical purposes) enough entropy available for urandom to work securely.

The first-boot problems were amplified by the fact that we were running our nodes inside virtualization. (At the time: UML, and we built our own on top of it. Xen wasn't nearly ready enough back then.)

It's fascinating to see that the problems we had to deal with 10 years ago are now becoming an issue again. To this day I choose to use /dev/random if I need to generate key material shortly after boot (which could be install), or for my own long-term use. Good thing personal GPG keys have a shelf-life of several years...

[blazespin]

Lordy. Hyperbole much? There are cases where I am sure having access to a blocking source of entropy is interesting. Perhaps it has nothing to do with crypto. Maybe it's mathematical or scientific in nature. Who knows. But it's good to give developers an option and not cut off access to useful tools because you think they can't handle it.

[Tomte]

In which way are those platform guarantees? Honest question, I don't understand where you're getting at.