3 ms·

If you choose a bad implementation of your crypto primitives (ones that don't make these kinds of checks) then you will get bad results. That's not surprising.

If you choose a bad implementation of your crypto primitives (ones that don't make these kinds of checks) then you will get bad results. That's not surprising. The same thing happens when you choose a bad TLS implementation. Your argument is that you should use a well-known TLS stack because the bugs have been shaken out over the years. I agree with that. But, the same thing applies to the lower-level crypto protocol implementations. The common TLS implementations are implemented with the common crypto primitive implementations. For example, IIRC the checks of D-H parameters in OpenSSL are in the D-H code, not in the TLS code. So, you don't need to use the TLS part of OpenSSL to get the benefits of its carefully-written D-H implementation. I'm not saying that anybody should go out and implement all the primitives (D-H, ECC, AES, GCM) themselves.

tptacek 17y ago
What's the recommendation you would make to a generalist developer on a library they can safely use to implement their own secure transport with ephemeral keying? You sound very clueful but I don't think you've thought this through. Off the top of my head I can think of zero popular cryptosystems that haven't been burned by terrible implementation flaws. I just told you that Tor, which was implemented by someone who got a PhD under Rivest, managed to screw up DH. Your response is, "if you picked better libraries, you'd do better than Roger Dingledine". No, you wouldn't.
- briansmith 17y ago
  The specific bug you mentioned really was the result of writing/choosing a bad D-H library. But, I agree with your your point that, even if you have a security expert on board, you are likely to make mistakes. If Tor would have used an off-then-shelf D-H implementation that already performed that check, it wouldn't have had the vulnerability. It is definitely easier to pick a TLS implementation that is unlikely to have such flaws (now)--just pick what lots of others have been using for a long time. You could do the same with crypto primitive implementations, but you run into problems because the interfaces for different libraries are all different, and in particular the preconditions and postconditions of various operations might be different. So, user of a crypto library has to fully understand all the details in order to verify what is his responsibility and what is the library's responsibility. It would be great if there was a specification that specified what every D-H implementation must do, and what the user of a D-H implementation must do to be safe. Actually, a similar problem exists with TLS. Right now there is a draft TLS spec. that attempts to standardize how TLS implementations check a server's certificate against the server's domain name. Since there's no standard way of doing it, its harder to verify that a given TLS implementation is actually doing it the right way. And, actually, this is something that OpenSSL and other TLS implementations punt on and force the application to deal with manually. As I'm sure you've seen, lots of applications actually don't even check at all!

tptacek 17y ago

What's the recommendation you would make to a generalist developer on a library they can safely use to implement their own secure transport with ephemeral keying? You sound very clueful but I don't think you've thought this through. Off the top of my head I can think of zero popular cryptosystems that haven't been burned by terrible implementation flaws. I just told you that Tor, which was implemented by someone who got a PhD under Rivest, managed to screw up DH. Your response is, "if you picked better libraries, you'd do better than Roger Dingledine". No, you wouldn't.

briansmith 17y ago
The specific bug you mentioned really was the result of writing/choosing a bad D-H library. But, I agree with your your point that, even if you have a security expert on board, you are likely to make mistakes. If Tor would have used an off-then-shelf D-H implementation that already performed that check, it wouldn't have had the vulnerability. It is definitely easier to pick a TLS implementation that is unlikely to have such flaws (now)--just pick what lots of others have been using for a long time. You could do the same with crypto primitive implementations, but you run into problems because the interfaces for different libraries are all different, and in particular the preconditions and postconditions of various operations might be different. So, user of a crypto library has to fully understand all the details in order to verify what is his responsibility and what is the library's responsibility. It would be great if there was a specification that specified what every D-H implementation must do, and what the user of a D-H implementation must do to be safe. Actually, a similar problem exists with TLS. Right now there is a draft TLS spec. that attempts to standardize how TLS implementations check a server's certificate against the server's domain name. Since there's no standard way of doing it, its harder to verify that a given TLS implementation is actually doing it the right way. And, actually, this is something that OpenSSL and other TLS implementations punt on and force the application to deal with manually. As I'm sure you've seen, lots of applications actually don't even check at all!