6 ms·

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

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.

Tomte 13y ago
In which way are those platform guarantees? Honest question, I don't understand where you're getting at.
fulafel 13y ago
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 13y ago
  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-stable.git/tree/drivers/char/random.c?id=HEAD#n98 http://git.kernel.org/cgit/linux/kernel/git/stable/linux-sta...
  - fulafel 13y ago
    That's a comment block in the Linux random.c code titled "Theory of Operation"...
    - throwaway092834 13y ago
      Correct.
tptacek 13y ago
No. Applications on Linux should use urandom to the exclusion of any other CSPRNG.
- bostik 13y ago
  > 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...
  - tptacek 13y ago
    If you're building an appliance, why wouldn't you simply ensure urandom is seeded at first boot? I'm sympathetic to people's concerns about generating long-term keys. But my problem is, /dev/random isn't addressing the major risks there either. You should generate long-term keys on entirely separate hardware.
- blazespin 13y ago
  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 13y ago

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

fulafel 13y ago

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 13y ago
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-stable.git/tree/drivers/char/random.c?id=HEAD#n98 http://git.kernel.org/cgit/linux/kernel/git/stable/linux-sta...
- fulafel 13y ago
  That's a comment block in the Linux random.c code titled "Theory of Operation"...
  - throwaway092834 13y ago
    Correct.

tptacek 13y ago

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

bostik 13y ago
> 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...
- tptacek 13y ago
  If you're building an appliance, why wouldn't you simply ensure urandom is seeded at first boot? I'm sympathetic to people's concerns about generating long-term keys. But my problem is, /dev/random isn't addressing the major risks there either. You should generate long-term keys on entirely separate hardware.
blazespin 13y ago
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.