5 ms·

Does jitter entropy mitigate the need to install haveged [1] on systems with high entropy requirements? [1] https://issihosts.com/haveged/ https://issihosts.co

Does jitter entropy mitigate the need to install haveged [1] on systems with high entropy requirements? [1] https://issihosts.com/haveged/ https://issihosts.com/haveged/

tptacek 7y ago
What is a "high entropy requirement"? It is hard for me to come up with a secure design that somehow depends on having haveged installed; in practice, you should never be using it.
- cobbzilla 7y ago
  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.
garaetjjte 7y ago
No, it doesn't prevent /dev/random from blocking when estimated entropy runs out.
- cobbzilla 7y ago
  Thank you. This is what I was asking.

Does jitter entropy mitigate the need to install haveged [1] on systems with high entropy requirements? [1] https://issihosts.com/haveged/ https://issihosts.com/haveged/

tptacek 7y ago

What is a "high entropy requirement"? It is hard for me to come up with a secure design that somehow depends on having haveged installed; in practice, you should never be using it.

cobbzilla 7y ago
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.

garaetjjte 7y ago

No, it doesn't prevent /dev/random from blocking when estimated entropy runs out.

cobbzilla 7y ago
Thank you. This is what I was asking.