8 ms·

it also provides the much-needed middle ground between /dev/random and /dev/urandom. What do you mean?

agwa 12y ago
/dev/urandom never blocks, even if it means returning randomness before the system has gathered enough entropy to safely seed a CSPRNG. /dev/random blocks whenever the system's "entropy count" is too low, even if the system has previously gathered enough entropy to produce secure randomness. The frequent blocking of /dev/random makes it unsuitable for practical use while providing questionable security benefit. getrandom() blocks only until the system has gathered enough entropy to safely seed a CSPRNG, and then never blocks again. (Assuming the GRND_BLOCK flag and not the GRND_RANDOM flag.) An in-depth explanation: http://www.2uo.de/myths-about-urandom/ http://www.2uo.de/myths-about-urandom/
- sillysaurus3 12y ago
  From your link: /dev/urandom is insecure. Always use /dev/random for cryptographic purposes. Fact: /dev/urandom is the preferred source of cryptographic randomness on UNIX-like systems. This seems to contradict your first point, which is that /dev/urandom is insecure in some situations. (Returning randomness without sufficient entropy is a security problem.) Can urandom ever be used insecurely? Tptacek has said many times that you should just seed /dev/urandom from /dev/random, then never use /dev/random again: http://hn.algolia.com/#!/comment/forever/prefix/0/author%3Atptacek%20urandom http://hn.algolia.com/#!/comment/forever/prefix/0/author%3At... Is LibreSSL's situation different? If so, why?
  - agwa 12y ago
    Further down, under "Not everything is perfect," the author addresses the problem with /dev/urandom never blocking. Seeding /dev/urandom from /dev/random is a trick that can be used early in the boot sequence to ensure that /dev/urandom is henceforth secure. (In practice, distros carry over a seed from the previous boot which accomplishes the same effect.)
- tptacek 12y ago
  I'm not really thrilled with the idea that you should use urandom to seed a CSPRNG; urandom should be your only CSPRNG. This most recent libressl kerfuffle is an illustration of why userspace CSPRNGs are a bad idea.
  - agwa 12y ago
    When I said "seed a CSPRNG" I was talking about the kernel seeding its own CSPRNG. I agree that just using the kernel's CSPRNG is the sanest solution to this mess.
    - giovannibajo1 12y ago
      > I agree that just using the kernel's CSPRNG is the sanest solution to this mess. well, you agree up to the point you actually need to convert your words into facts, at that point you don't agree anymore :) https://github.com/AGWA/git-crypt/commit/34432e915e8415b112c09dc1a50366a457d0322e https://github.com/AGWA/git-crypt/commit/34432e915e8415b112c...
      - agwa 12y ago
        Oh boy, I should have seen this one coming :-) By "this mess" I meant the LibreSSL fork/chroot mess. I think crypto libraries should just use whatever the OS provides and not try to implement their own CSPRNGs. But git-crypt is a cross-platform application, not a crypto library. Implementing my own cross-platform wrapper around OS CSPRNGs would be decidedly less sane (and more error-prone) than just using the crypto library's CSPRNG, even if I disagree with how the library has done things.
  - Terr_ 12y ago
    I know you said "CS-", but seed-able PRNGs in user-space can be immensely useful in tons of other situations, allowing things to be debugged, replayed, and synchronized. So even if you convince to use urandom for their crypto needs on *nix platforms, it'll still have to be easy to seed one in userspace if someone really wanted to.
- derefr 12y ago
  I know that we need to support old programs that expect these behaviours of these device nodes. However, how about a workaround like "udev only creates /dev/urandom once /dev/random has been seeded"?
klodolph 12y ago
/dev/random is too severe. It's basically designed to be an information-theoretic random source, which means you could use its output as a one-time pad even if your adversary were time-travelling deities with countless universes full of quantum computers at their disposal. It blocks when you try to use it if there aren't enough bits to satisfy this. /dev/urandom is too loose. It's designed to be computationally secure, which means that you could use it if your adversaries were stuck in our universe and had to make their computers out of matter and power them with energy. However, it never blocks, even if there isn't enough entropy in the pool. We just need a PRNG that will spit out numbers as long as, say, 256 random bits were added to the pool at some point. Once you have that many bits, just keep on spitting out numbers.
- tptacek 12y ago
  Pedantry, not really focused on you: urandom is not too loose. There is exactly one Linux issue with urandom: it will service requests before the urandom pool is initialized. Linux distros work around this by trying to make sure urandom is initialized securely very early in the boot process. Once urandom is initialized, the idea that it can ever "run out of entropy" is nonsensical; urandom is structurally the same as a stream cipher keystream generator, and we generally don't fret about whether AES-CTR keystreams will "run out of key". Nonetheless, the belief that urandom will sporadically "run out of entropy" is virulent. The motivation behind the new system call has more to do with chroot environments, where the device might not be available at all. It's a good change; randomness should be provided by a system call and not a device. Unfortunately, by adding the flag, they've basically managed to add two system calls: getrandom and geturandom. >HEADDESK<
  - blazespin 12y ago
    There's been a lot of papers about urandom being a broken pool. They need to adopt something like Fortuna or one of the more modern formalisms of Fortuna.
    - tptacek 12y ago
      The Linux urandom pool is managed almost identically to the random pool. The fact that random is "safe" (if blocking makes you safe) immediately after cold boot is actually just a side effect.

agwa 12y ago

/dev/urandom never blocks, even if it means returning randomness before the system has gathered enough entropy to safely seed a CSPRNG. /dev/random blocks whenever the system's "entropy count" is too low, even if the system has previously gathered enough entropy to produce secure randomness. The frequent blocking of /dev/random makes it unsuitable for practical use while providing questionable security benefit. getrandom() blocks only until the system has gathered enough entropy to safely seed a CSPRNG, and then never blocks again. (Assuming the GRND_BLOCK flag and not the GRND_RANDOM flag.) An in-depth explanation: http://www.2uo.de/myths-about-urandom/ http://www.2uo.de/myths-about-urandom/

sillysaurus3 12y ago
From your link: /dev/urandom is insecure. Always use /dev/random for cryptographic purposes. Fact: /dev/urandom is the preferred source of cryptographic randomness on UNIX-like systems. This seems to contradict your first point, which is that /dev/urandom is insecure in some situations. (Returning randomness without sufficient entropy is a security problem.) Can urandom ever be used insecurely? Tptacek has said many times that you should just seed /dev/urandom from /dev/random, then never use /dev/random again: http://hn.algolia.com/#!/comment/forever/prefix/0/author%3Atptacek%20urandom http://hn.algolia.com/#!/comment/forever/prefix/0/author%3At... Is LibreSSL's situation different? If so, why?
- agwa 12y ago
  Further down, under "Not everything is perfect," the author addresses the problem with /dev/urandom never blocking. Seeding /dev/urandom from /dev/random is a trick that can be used early in the boot sequence to ensure that /dev/urandom is henceforth secure. (In practice, distros carry over a seed from the previous boot which accomplishes the same effect.)
tptacek 12y ago
I'm not really thrilled with the idea that you should use urandom to seed a CSPRNG; urandom should be your only CSPRNG. This most recent libressl kerfuffle is an illustration of why userspace CSPRNGs are a bad idea.
- agwa 12y ago
  When I said "seed a CSPRNG" I was talking about the kernel seeding its own CSPRNG. I agree that just using the kernel's CSPRNG is the sanest solution to this mess.
  - giovannibajo1 12y ago
    > I agree that just using the kernel's CSPRNG is the sanest solution to this mess. well, you agree up to the point you actually need to convert your words into facts, at that point you don't agree anymore :) https://github.com/AGWA/git-crypt/commit/34432e915e8415b112c09dc1a50366a457d0322e https://github.com/AGWA/git-crypt/commit/34432e915e8415b112c...
    - agwa 12y ago
      Oh boy, I should have seen this one coming :-) By "this mess" I meant the LibreSSL fork/chroot mess. I think crypto libraries should just use whatever the OS provides and not try to implement their own CSPRNGs. But git-crypt is a cross-platform application, not a crypto library. Implementing my own cross-platform wrapper around OS CSPRNGs would be decidedly less sane (and more error-prone) than just using the crypto library's CSPRNG, even if I disagree with how the library has done things.
- Terr_ 12y ago
  I know you said "CS-", but seed-able PRNGs in user-space can be immensely useful in tons of other situations, allowing things to be debugged, replayed, and synchronized. So even if you convince to use urandom for their crypto needs on *nix platforms, it'll still have to be easy to seed one in userspace if someone really wanted to.
derefr 12y ago
I know that we need to support old programs that expect these behaviours of these device nodes. However, how about a workaround like "udev only creates /dev/urandom once /dev/random has been seeded"?

klodolph 12y ago

/dev/random is too severe. It's basically designed to be an information-theoretic random source, which means you could use its output as a one-time pad even if your adversary were time-travelling deities with countless universes full of quantum computers at their disposal. It blocks when you try to use it if there aren't enough bits to satisfy this. /dev/urandom is too loose. It's designed to be computationally secure, which means that you could use it if your adversaries were stuck in our universe and had to make their computers out of matter and power them with energy. However, it never blocks, even if there isn't enough entropy in the pool. We just need a PRNG that will spit out numbers as long as, say, 256 random bits were added to the pool at some point. Once you have that many bits, just keep on spitting out numbers.

tptacek 12y ago
Pedantry, not really focused on you: urandom is not too loose. There is exactly one Linux issue with urandom: it will service requests before the urandom pool is initialized. Linux distros work around this by trying to make sure urandom is initialized securely very early in the boot process. Once urandom is initialized, the idea that it can ever "run out of entropy" is nonsensical; urandom is structurally the same as a stream cipher keystream generator, and we generally don't fret about whether AES-CTR keystreams will "run out of key". Nonetheless, the belief that urandom will sporadically "run out of entropy" is virulent. The motivation behind the new system call has more to do with chroot environments, where the device might not be available at all. It's a good change; randomness should be provided by a system call and not a device. Unfortunately, by adding the flag, they've basically managed to add two system calls: getrandom and geturandom. >HEADDESK<
- blazespin 12y ago
  There's been a lot of papers about urandom being a broken pool. They need to adopt something like Fortuna or one of the more modern formalisms of Fortuna.
  - tptacek 12y ago
    The Linux urandom pool is managed almost identically to the random pool. The fact that random is "safe" (if blocking makes you safe) immediately after cold boot is actually just a side effect.