4 ms·

Use system random generator in crypto

22 points by sr2 9y ago

deleted 9y ago
[deleted]
Phithagoras 9y ago
Blog post at https://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/ https://sockpuppet.org/blog/2014/02/25/safely-generate-rando...
cwmma 9y ago
tl;dr is basically on one side a suggestion to move away from the prng included in openssl because it could have bug, could be used wrong, and doesn't add anything from a cryptographic perspective and instead directly use the OS methods of generating randomness. There is then a lot of resistance to this on the grounds that fixing these theoretical bugs could add real bugs and considering how many OSs need to be supported this would trend towards rolling one's own crypto which the maintainers do NOT want to do. There is openness though towards bundling libsodium and using it to generate randomness.
- glandium 9y ago
  > move away from the prng included in openssl because it could have bug, could be used wrong, (...) and instead directly use the OS methods of generating randomness. This could phrased as: move away from a prng that could have bugs, could be used wrong and instead use a different prng that could have bugs and could be used wrong. And each platform would use a different prng. Put this way, it's not really enticing.
  - deleted 9y ago
    [deleted]
  - LgWoodenBadger 9y ago
    It's a move to eliminate a dependency that provides no extra security (and likely weakens security). The dependency they want to eliminate (OpenSSL) ALREADY relies on the "different prng that could have bugs and could be used wrong." The only thing they would gain is not having to handle platform-dependent issues reading from system's prng (which is only really different on Windows?).
gumby 9y ago
side question: any recommendations for a good, portable, linear prng in C++ we can embed in some proprietary code? We are doing some simulations which we run on multiple architectures and sometimes want to re run with different input parameters...and so want the same stream of "random" numbers for multiple runs. My understanding (perhaps wrong?) is that open openSSL prng is exponential.
- tptacek 9y ago
  What's "good"? If security doesn't matter, for your application, random(3) might do just fine. One simple way to generate a deterministic RNG is to run a hash or a cipher (encrypting an all zeroes block, or a secret) in counter mode. MD5 of some application secret and a counter might suffice for you (it will be plenty fast).
- wolf550e 9y ago
  "exponential" in what? You can just encrypt a counter using AES or ChaCha ([1]) to produce 2^68 random bytes from 24 initial bytes. You can use HKDF to expand 16 bytes into as many key+nonce pairs as you want, each producing 2^68 random bytes. 1 - use AES if your hardware has AESNI, my mobile i7 can do AES at 5GB/sec on a single core
  - gumby 9y ago
    Thanks, this is a good idea. We don't need fast, we need repeatable so that the same seed into the same prng produces the same number on different machines (different CPUs, different OSes) which is why we want to change from simply using the system facilities as we do now. Yet the number of calls to rand() in each simulation is high enough that we don't want to simply keep a large table of random numbers.
    - wolf550e 9y ago
      AES and ChaCha are very repeatable. :-) They also happen to be fast.
tptacek 9y ago
I'm not a fan of this genre of HN posts, where we're encouraged to read lurid displays of (for lack of any better word, but without intending much value judgement) ignorance about some highly technical issue. It's clear the Node team members do not have an especially good grasp on the problem here (you don't need to read all the way to the part where they talk about mixing in getpid to come to that conclusion). It's also a little clear to me that the blunt-force approach of patrolling major open source projects for bad RNGs and demanding they replace them with urandom is unlikely to be productive. It becomes clear pretty quickly in this thread that the "no" votes have basically been cornered, message board flamewar style, and can't reconsider without losing face. At the core of this discussion is a misunderstanding of the fundamental problem with elaborate CSPRNGs --- a misunderstanding the "urandom" votes here don't do a very good job of clearing up. Specifically: the problem isn't having enough entropy; a very small amount of entropy can be cryptographically stretched into a practically unbounded feed of random bits. The value of adding more entropy is future secrecy (in effect: key rotation), which is a systems concern more than a cryptographic concern. Rather, the problem with elaborate CSPRNGs is the handling of whatever entropy you collect, be it a mere 256 bits or a continuous running feed of userspace entropy. It's that concern that has repeatedly blown up crypto programs, and it's that concern that motivates us to rely on the kernel's systemwide random number generator rather than schemes like "egd", because the kernel CSPRNG is simpler, is a dependency in all systems anyways, can make promises about sharing that are hard for userspace programs to make, and can extract promises from the hardware that are not made directly to userspace programs.

22 points by sr2 9y ago

deleted 9y ago

[deleted]

Blog post at https://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/ https://sockpuppet.org/blog/2014/02/25/safely-generate-rando...

cwmma 9y ago

tl;dr is basically on one side a suggestion to move away from the prng included in openssl because it could have bug, could be used wrong, and doesn't add anything from a cryptographic perspective and instead directly use the OS methods of generating randomness. There is then a lot of resistance to this on the grounds that fixing these theoretical bugs could add real bugs and considering how many OSs need to be supported this would trend towards rolling one's own crypto which the maintainers do NOT want to do. There is openness though towards bundling libsodium and using it to generate randomness.

glandium 9y ago
> move away from the prng included in openssl because it could have bug, could be used wrong, (...) and instead directly use the OS methods of generating randomness. This could phrased as: move away from a prng that could have bugs, could be used wrong and instead use a different prng that could have bugs and could be used wrong. And each platform would use a different prng. Put this way, it's not really enticing.
- deleted 9y ago
  [deleted]
- LgWoodenBadger 9y ago
  It's a move to eliminate a dependency that provides no extra security (and likely weakens security). The dependency they want to eliminate (OpenSSL) ALREADY relies on the "different prng that could have bugs and could be used wrong." The only thing they would gain is not having to handle platform-dependent issues reading from system's prng (which is only really different on Windows?).

gumby 9y ago

side question: any recommendations for a good, portable, linear prng in C++ we can embed in some proprietary code? We are doing some simulations which we run on multiple architectures and sometimes want to re run with different input parameters...and so want the same stream of "random" numbers for multiple runs. My understanding (perhaps wrong?) is that open openSSL prng is exponential.

tptacek 9y ago
What's "good"? If security doesn't matter, for your application, random(3) might do just fine. One simple way to generate a deterministic RNG is to run a hash or a cipher (encrypting an all zeroes block, or a secret) in counter mode. MD5 of some application secret and a counter might suffice for you (it will be plenty fast).
wolf550e 9y ago
"exponential" in what? You can just encrypt a counter using AES or ChaCha ([1]) to produce 2^68 random bytes from 24 initial bytes. You can use HKDF to expand 16 bytes into as many key+nonce pairs as you want, each producing 2^68 random bytes. 1 - use AES if your hardware has AESNI, my mobile i7 can do AES at 5GB/sec on a single core
- gumby 9y ago
  Thanks, this is a good idea. We don't need fast, we need repeatable so that the same seed into the same prng produces the same number on different machines (different CPUs, different OSes) which is why we want to change from simply using the system facilities as we do now. Yet the number of calls to rand() in each simulation is high enough that we don't want to simply keep a large table of random numbers.
  - wolf550e 9y ago
    AES and ChaCha are very repeatable. :-) They also happen to be fast.

tptacek 9y ago

I'm not a fan of this genre of HN posts, where we're encouraged to read lurid displays of (for lack of any better word, but without intending much value judgement) ignorance about some highly technical issue. It's clear the Node team members do not have an especially good grasp on the problem here (you don't need to read all the way to the part where they talk about mixing in getpid to come to that conclusion). It's also a little clear to me that the blunt-force approach of patrolling major open source projects for bad RNGs and demanding they replace them with urandom is unlikely to be productive. It becomes clear pretty quickly in this thread that the "no" votes have basically been cornered, message board flamewar style, and can't reconsider without losing face. At the core of this discussion is a misunderstanding of the fundamental problem with elaborate CSPRNGs --- a misunderstanding the "urandom" votes here don't do a very good job of clearing up. Specifically: the problem isn't having enough entropy; a very small amount of entropy can be cryptographically stretched into a practically unbounded feed of random bits. The value of adding more entropy is future secrecy (in effect: key rotation), which is a systems concern more than a cryptographic concern. Rather, the problem with elaborate CSPRNGs is the handling of whatever entropy you collect, be it a mere 256 bits or a continuous running feed of userspace entropy. It's that concern that has repeatedly blown up crypto programs, and it's that concern that motivates us to rely on the kernel's systemwide random number generator rather than schemes like "egd", because the kernel CSPRNG is simpler, is a dependency in all systems anyways, can make promises about sharing that are hard for userspace programs to make, and can extract promises from the hardware that are not made directly to userspace programs.