5 ms·

The most common is an internal CA server (certificate authority) that needs to generate many certs on demand.

tptacek 7y ago
What about that environment needs "extra" entropy? You either have entropy or you don't; the volume of signings you do doesn't have anything to do with it.
- cobbzilla 7y ago
  Reading from `/dev/random` (true randomness) will block if there is insufficient system entropy available. You can read the currently available amount via `cat /proc/sys/kernel/random/entropy_avail`. If you have an SLA that guarantees true randomness, and a certain response time or availability, you cannot really afford to block indefinitely while Linux builds up more entropy via its natural mechanisms. Augmenting with haveged is pretty common, all it does is add more sources of randomness. I was hoping that jitter entropy (which seems kinda like the same thing) would alleviate the need to install one more package in these cases, but it's not clear. I will have to try it out sometime.
  - morelisp 7y ago
    > Augmenting with haveged is pretty common So was snake oil.
  - CiPHPerCoder 7y ago
    > Reading from `/dev/random` (true randomness) /dev/random doesn't provide "true randomness". /dev/random and /dev/urandom provide the same kind of randomness. The difference is that, for 99.999% of developers, /dev/random blocks for no good reason. All haveged does is pollute the kernel entropy pool to make /dev/random less unstable in production. https://www.2uo.de/myths-about-urandom https://www.2uo.de/myths-about-urandom
    - cobbzilla 7y ago
      It's complicated. https://www.mail-archive.com/cryptography@randombit.net/msg04771.html https://www.mail-archive.com/cryptography@randombit.net/msg0...
      - tptacek 7y ago
        No, it's not. The old man page was incredibly confusing and misleading and has created a weird culture of fear around a simple issue. What you care about is whether the RNG is securely seeded or not. Once it is, you don't care anymore. Think of an RNG like a stream cipher (which is what many of them are under the hood). Key AES-CTR with a 128 bit random key and run it to generate all the "random bytes" you will ever realistically use in any usage scenario. AES never "runs out of key". In the same way, a CSPRNG never "runs out of entropy". We regularly re-key the system CSPRNG (by updating it, in the kernel, with "more entropy"), but not because entropy is depleted; rather, because it provides a measure of future security: if our machine is compromised, but only briefly, we don't want attackers to permanently predict the outputs of the RNG. What you want are random/urandom interfaces that block at system startup until the RNG is seeded, and never again. What you do not want are userland CSPRNGs and CPSRNG "helpers"; those aren't solving real problems, have in the past introduced horrible security vulnerabilities, and perpetuate confusion about the security properties we're looking for. Sign one X.509 certificate or ten million of them; the same initial secure dose of "entropy" will do just fine.
      - CiPHPerCoder 7y ago
        An archived email to a mailing list from one person in 2013 that can never be corrected or amended isn't the most reliable way to spread information about cryptography engineering. What does Gutmann say in 2019 about /dev/urandom vs /dev/random? Which of the two do JP Aumasson (author of Serious Cryptography and inventor of several cryptography algorithms used today, including BLAKE2 and SipHash), Dan Bernstein (Salsa20, ChaCha20, Poly1305, Curve25519, Ed25519, etc.), Matthew Green (professor associated with the TrueCrypt audit), et al. prefer in their own designs? I can promise you the answer is /dev/urandom. Why do they prefer /dev/urandom? Because of the reasons outlined in the article I linked (which, unlike the mailing list post you linked, is occasionally updated with corrections). It's not really that complicated: Use /dev/urandom. If you're on an ancient Linux kernel, you can poll /dev/random until it's available if you're uncertain whether or not /dev/urandom has ever been seeded. Once /dev/random is available, don't use /dev/random, use /dev/urandom. This side-steps the "/dev/urandom never blocks" concern that people love to cite in their fearmongering. This is essentially what getrandom(2) does. If you're on a recent Linux kernel, you can say "just use getrandom(2)" instead of "just use /dev/urandom", but the premise of the discussion is whether to use /dev/random or /dev/urandom not which of all possible options should be used. See also: https://paragonie.com/blog/2016/05/how-generate-secure-random-numbers-in-various-programming-languages https://paragonie.com/blog/2016/05/how-generate-secure-rando... The belief that /dev/random must somehow be better than /dev/urandom is, frankly, security theater.

What about that environment needs "extra" entropy? You either have entropy or you don't; the volume of signings you do doesn't have anything to do with it.

cobbzilla 7y ago
Reading from `/dev/random` (true randomness) will block if there is insufficient system entropy available. You can read the currently available amount via `cat /proc/sys/kernel/random/entropy_avail`. If you have an SLA that guarantees true randomness, and a certain response time or availability, you cannot really afford to block indefinitely while Linux builds up more entropy via its natural mechanisms. Augmenting with haveged is pretty common, all it does is add more sources of randomness. I was hoping that jitter entropy (which seems kinda like the same thing) would alleviate the need to install one more package in these cases, but it's not clear. I will have to try it out sometime.
- morelisp 7y ago
  > Augmenting with haveged is pretty common So was snake oil.
- CiPHPerCoder 7y ago
  > Reading from `/dev/random` (true randomness) /dev/random doesn't provide "true randomness". /dev/random and /dev/urandom provide the same kind of randomness. The difference is that, for 99.999% of developers, /dev/random blocks for no good reason. All haveged does is pollute the kernel entropy pool to make /dev/random less unstable in production. https://www.2uo.de/myths-about-urandom https://www.2uo.de/myths-about-urandom
  - cobbzilla 7y ago
    It's complicated. https://www.mail-archive.com/cryptography@randombit.net/msg04771.html https://www.mail-archive.com/cryptography@randombit.net/msg0...
    - tptacek 7y ago
      No, it's not. The old man page was incredibly confusing and misleading and has created a weird culture of fear around a simple issue. What you care about is whether the RNG is securely seeded or not. Once it is, you don't care anymore. Think of an RNG like a stream cipher (which is what many of them are under the hood). Key AES-CTR with a 128 bit random key and run it to generate all the "random bytes" you will ever realistically use in any usage scenario. AES never "runs out of key". In the same way, a CSPRNG never "runs out of entropy". We regularly re-key the system CSPRNG (by updating it, in the kernel, with "more entropy"), but not because entropy is depleted; rather, because it provides a measure of future security: if our machine is compromised, but only briefly, we don't want attackers to permanently predict the outputs of the RNG. What you want are random/urandom interfaces that block at system startup until the RNG is seeded, and never again. What you do not want are userland CSPRNGs and CPSRNG "helpers"; those aren't solving real problems, have in the past introduced horrible security vulnerabilities, and perpetuate confusion about the security properties we're looking for. Sign one X.509 certificate or ten million of them; the same initial secure dose of "entropy" will do just fine.
    - CiPHPerCoder 7y ago
      An archived email to a mailing list from one person in 2013 that can never be corrected or amended isn't the most reliable way to spread information about cryptography engineering. What does Gutmann say in 2019 about /dev/urandom vs /dev/random? Which of the two do JP Aumasson (author of Serious Cryptography and inventor of several cryptography algorithms used today, including BLAKE2 and SipHash), Dan Bernstein (Salsa20, ChaCha20, Poly1305, Curve25519, Ed25519, etc.), Matthew Green (professor associated with the TrueCrypt audit), et al. prefer in their own designs? I can promise you the answer is /dev/urandom. Why do they prefer /dev/urandom? Because of the reasons outlined in the article I linked (which, unlike the mailing list post you linked, is occasionally updated with corrections). It's not really that complicated: Use /dev/urandom. If you're on an ancient Linux kernel, you can poll /dev/random until it's available if you're uncertain whether or not /dev/urandom has ever been seeded. Once /dev/random is available, don't use /dev/random, use /dev/urandom. This side-steps the "/dev/urandom never blocks" concern that people love to cite in their fearmongering. This is essentially what getrandom(2) does. If you're on a recent Linux kernel, you can say "just use getrandom(2)" instead of "just use /dev/urandom", but the premise of the discussion is whether to use /dev/random or /dev/urandom not which of all possible options should be used. See also: https://paragonie.com/blog/2016/05/how-generate-secure-random-numbers-in-various-programming-languages https://paragonie.com/blog/2016/05/how-generate-secure-rando... The belief that /dev/random must somehow be better than /dev/urandom is, frankly, security theater.