3 ms·

Vulnerabilities such as accidentally setting a value (g[x] or g[y], or x, or y IIRC) to 1 and then having the keys generated be invalid because the key would en

Vulnerabilities such as accidentally setting a value (g[x] or g[y], or x, or y IIRC) to 1 and then having the keys generated be invalid because the key would end up being 1? Wasn't this an issue in an IPSEC implementation? Or are you talking about the no authentication on DH so that MITM is trivially possible? Or the choosing of bad prime numbers (hence my suggestion of using the NIST groups) could mean it is easier for an attacker to figure out the private key that is generated. Speaking of which, this paper which I read a while back is definitely a good idea for reading before implementing DH: http://crypto.cs.mcgill.ca/~stiglic/Papers/dhfull.pdf http://crypto.cs.mcgill.ca/~stiglic/Papers/dhfull.pdf Do I feel confident how to tell generalist developers how to do crypto? Not entirely, but I do feel confident telling generalist developers what I have seen that is completely wrong or what has to be avoided. As for the encrypt then mac, I'd definitely agree with you there, and also agree that public key may not be the best, but the option should exist. For what I am currently working on it is encrypted then HMAC the encrypted data, then the HMAC is stored publicly but the key for the HMAC is encrypted with public key, then that encrypted data is signed with private key. Now the receiver verifies signature with senders public, decrypts symmetric key/iv/hmac key with private key, and then verifies HMAC for data, then decrypts the data. Which as far as I am aware (and please correct me if I am wrong) is the best way to make sure that the data has not been tampered with.

tptacek 14y ago
Zero-mod-p was an IPSEC fault, as was subgroup negotiation (but you mentioned NIST groups earlier). Lots of people have done their own implementations of DH (DH is trivial to implement; it's just a couple lines of Ruby); how many of them do you think caught these flaws? I have no idea what the utility of the public key is in the system you just described. Public key crypto adds susceptibility to attack; it doesn't ever really spare you from it. Here, you're vulnerable both to attacks on your HMAC verification and to implementation flaws in your more number-theoretic (and way more dangerous) public key code.
- X-Istence 14y ago
  Indeed, DH can be difficult to get right if you are not paying attention. I wish I could go into more specifics for our implementation and what it is we do. Either way the public/private key stuff is done using various "high" level libraries that make reasonable choices and are audited, so it is not code that we are implementing ourselves, nor is the HMAC. So long as there are no issues in the libraries I should be fairly good. Thanks for the discussion :-).

tptacek 14y ago

Zero-mod-p was an IPSEC fault, as was subgroup negotiation (but you mentioned NIST groups earlier). Lots of people have done their own implementations of DH (DH is trivial to implement; it's just a couple lines of Ruby); how many of them do you think caught these flaws? I have no idea what the utility of the public key is in the system you just described. Public key crypto adds susceptibility to attack; it doesn't ever really spare you from it. Here, you're vulnerable both to attacks on your HMAC verification and to implementation flaws in your more number-theoretic (and way more dangerous) public key code.

X-Istence 14y ago
Indeed, DH can be difficult to get right if you are not paying attention. I wish I could go into more specifics for our implementation and what it is we do. Either way the public/private key stuff is done using various "high" level libraries that make reasonable choices and are audited, so it is not code that we are implementing ourselves, nor is the HMAC. So long as there are no issues in the libraries I should be fairly good. Thanks for the discussion :-).