5 ms·

The IETF TLS working group has included a relevant suggestion in the TLS1.3 draft RFC: https://github.com/tlswg/tls13-spec/commit/465de0e189b2b59090d0eac0acbc4

The IETF TLS working group has included a relevant suggestion in the TLS1.3 draft RFC: https://github.com/tlswg/tls13-spec/commit/465de0e189b2b59090d0eac0acbc42942af9ca77 https://github.com/tlswg/tls13-spec/commit/465de0e189b2b5909... The idea is simple: use two different instances of a secure RNG. One for "public" material that can be seen on the wire, which would include server and client random data. Another for "secret" material such as the private parts of DH parameters. With that set up, it's hard to impossible for DUAL_EC style attacks to work. Even if the RNG is "broken", there's nothing public to go-on to hint at what the state might be. We've been doing this in Amazon s2n since the first version, and I believe BouncyCastle does it too. Hopefully we'll see more implementations pick up the technique.

koolba 9y ago
> use two different instances of a secure RNG. One for "public" material that can be seen on the wire, which would include server and client random data. Another for "secret" material such as the private parts of DH parameters. Wow that's an incredibly simple solution. I feel like that general approach (where possible split client facing vs internal states) could be applied to many other places as well. Are there any problems with the additional initial entropy requirements to maintain separate RNGs (two per connection)? Or is it globally static, internal vs external?
- blattimwind 9y ago
  RNG state entropy is not a resource that is exhausted by using the RNG. But even if it were, and assuming entropy limitations are relevant in this context (which I'd argue they are not), the total entropy requirement would not change by merely deriving the same set of values in another way. You might only need more bytes (!= entropy) from your root RNG to seed two separate RNGs. In which case you could just stretch the same number of bytes you'd normally request using e.g. HKDF. But again, it doesn't make much sense to think of entropy as something you can count or use up, really. There is no way to tell, and just a few bits (say 128) of entropy would be sufficient for almost anything...
  - koolba 9y ago
    That’s what I’m referring to, retrieving more entropy from the system source to juice the initial state of the RNG. If you have a separate RNG per connection (or two per connection) that requires separate init, each connection would drain the system pool slightly. That’d be in constraint two having two static pools shared for all connections.
    - tptacek 9y ago
      No, what they're saying is that the notion that you can "drain" the system pool is an urban legend created by a bad Linux man page. In reality, entropy isn't really ever "drained" from the system entropy pool.
      - AgalmicVentures 9y ago
        Expanding on this, for anyone who wants to read more, http://www.2uo.de/myths-about-urandom/ http://www.2uo.de/myths-about-urandom/ is a good resource.
      - FeepingCreature 9y ago
        The pool's estimated isn't drained, but its "objective entropy" is reduced; ie. the amount of state leaked to the outside goes up. Of course, practically you can't recover that information within a usable timespan, so it's academic. Actually, now I sort of wonder what would happen if you encrypted a quantum superposition so that to determine which branch was taken would require reversing an operation using, at the lower bound, more computation than is available in the universe. Would it hold, or collapse/decohere?
  - cesarb 9y ago
    > RNG state entropy is not a resource that is exhausted by using the RNG. I thought so too, but a couple of years ago I was writing a comment on LWN (https://lwn.net/Articles/642839/ https://lwn.net/Articles/642839/) and it suddenly clicked. Entropy is a measure of unpredictability, that is, if you have 32 bits of entropy, there are 2^32 possible states. Suppose you generate an 8-bit value from that, assuming a function which uniformly mixes your state. For each of the possible 256 output values, on average 2^24 of the possible states would generate the same output value. Therefore, once you know the output value, you can discard the other 2^32 - 2^24 possibilities; only 2^24 possible states remain, so you now have only 24 bits of entropy left. The reason this is not a problem in practice is that, since the output function is one-way, an attacker would have to enumerate all possible states to find which ones would generate the same outputs. This becomes unfeasible once you have enough entropy in your state (256 bits or more). (The whole trick with Dual-EC was that, if you know the secret key, the output function is not one-way. Supposedly, either the key was discarded once generated, or the points were generated at random and not from a secret key, but nobody really believes that.)

koolba 9y ago

> use two different instances of a secure RNG. One for "public" material that can be seen on the wire, which would include server and client random data. Another for "secret" material such as the private parts of DH parameters. Wow that's an incredibly simple solution. I feel like that general approach (where possible split client facing vs internal states) could be applied to many other places as well. Are there any problems with the additional initial entropy requirements to maintain separate RNGs (two per connection)? Or is it globally static, internal vs external?

blattimwind 9y ago
RNG state entropy is not a resource that is exhausted by using the RNG. But even if it were, and assuming entropy limitations are relevant in this context (which I'd argue they are not), the total entropy requirement would not change by merely deriving the same set of values in another way. You might only need more bytes (!= entropy) from your root RNG to seed two separate RNGs. In which case you could just stretch the same number of bytes you'd normally request using e.g. HKDF. But again, it doesn't make much sense to think of entropy as something you can count or use up, really. There is no way to tell, and just a few bits (say 128) of entropy would be sufficient for almost anything...
- koolba 9y ago
  That’s what I’m referring to, retrieving more entropy from the system source to juice the initial state of the RNG. If you have a separate RNG per connection (or two per connection) that requires separate init, each connection would drain the system pool slightly. That’d be in constraint two having two static pools shared for all connections.
  - tptacek 9y ago
    No, what they're saying is that the notion that you can "drain" the system pool is an urban legend created by a bad Linux man page. In reality, entropy isn't really ever "drained" from the system entropy pool.
    - AgalmicVentures 9y ago
      Expanding on this, for anyone who wants to read more, http://www.2uo.de/myths-about-urandom/ http://www.2uo.de/myths-about-urandom/ is a good resource.
    - FeepingCreature 9y ago
      The pool's estimated isn't drained, but its "objective entropy" is reduced; ie. the amount of state leaked to the outside goes up. Of course, practically you can't recover that information within a usable timespan, so it's academic. Actually, now I sort of wonder what would happen if you encrypted a quantum superposition so that to determine which branch was taken would require reversing an operation using, at the lower bound, more computation than is available in the universe. Would it hold, or collapse/decohere?
- cesarb 9y ago
  > RNG state entropy is not a resource that is exhausted by using the RNG. I thought so too, but a couple of years ago I was writing a comment on LWN (https://lwn.net/Articles/642839/ https://lwn.net/Articles/642839/) and it suddenly clicked. Entropy is a measure of unpredictability, that is, if you have 32 bits of entropy, there are 2^32 possible states. Suppose you generate an 8-bit value from that, assuming a function which uniformly mixes your state. For each of the possible 256 output values, on average 2^24 of the possible states would generate the same output value. Therefore, once you know the output value, you can discard the other 2^32 - 2^24 possibilities; only 2^24 possible states remain, so you now have only 24 bits of entropy left. The reason this is not a problem in practice is that, since the output function is one-way, an attacker would have to enumerate all possible states to find which ones would generate the same outputs. This becomes unfeasible once you have enough entropy in your state (256 bits or more). (The whole trick with Dual-EC was that, if you know the secret key, the output function is not one-way. Supposedly, either the key was discarded once generated, or the points were generated at random and not from a secret key, but nobody really believes that.)