undefined | Better HN

0 pointsX-Istence13y ago0 comments

My code is not on Github because it is proprietary code, so unfortunately I can't send you a link to have a look at it.

Sure, encryption without authentication is worthless, but what if I want to do the authentication in a different manner? What if I want to encrypt using AES-128/CTR-BE and then sign using public/private key rather than using an HMAC(SHA-256). That choice can be left up to a developer. Also, there still seems to be some debate as to whether you encrypt then HMAC or if you HMAC then encrypt. (I personally prefer encrypt then HMAC).

I don't think you necessarily have to have the developer provide the IV, you can provide a way for the developer to get the generated IV back from the system after the fact that would work just as well. So long as you can get access to it, so you can build it to spec. All this hiding is good for projects where that is possible, interoperability and following gov't requirements can throw a wrench in simply using something like Keyczar.

The biggest issue with DH that we have had to overcome is the different encodings that may be used. You have various different standards for how to share the DH keys. There is an ANS X9 standard that is recommended by the government[1] (and required in our product) and then there is PKCS3.

The biggest issue we ran into is that Java (on Android) only does PKCS3, and Botan doesn't by default decode that so you end up having to implement that functionality yourself. We ended up using PKCS3 but that will most likely have to be changed for gov't approval which means we need to get Java to grok ANS X9.

When doing DH I also suggest using one of the NIST approved DH groups and not generating your own.

Do note that none of this is using a custom DH implementation, it is using the stuff that is available in Botan/Java itself, the biggest issue is finding common ground for finishing the DH key exchange because of the different formats used in the in-between steps.

Also, generating a random key from the DH data is different on various different API's. Botan can generate keys for you, and will use a KDF for you, while Java will simply give you the bytes back in raw format.

So far this isn't a solved problem for us. Since we are not using it for cryptographic purposes we may end up doing our own custom implementation so that we have less to worry about in terms of encoding/decoding various different storage schemes. And any weakness in the system won't be a fatal flaw that could be used/exploited in a meaningful manner, so fixing things at a later date won't be catastrophic.

The biggest issue is that there are so many standards and so many little variations of it in cryptography that trying to get systems to interoperate and work together is a massive undertaking and each time you run up against a wall because something is abstracted away you wish and eventually want access to the lower level primitives.

[1]: http://csrc.nist.gov/publications/nistpubs/800-56A/SP800-56A...

0 comments

3 comments · 1 top-level

tptacek13y ago· 2 in thread

I mean, there are widespread DH vulnerabilities that are trivial to test for that you haven't mentioned here. Obviously, you've written code to do DH before, and crypto code in general, but how confident do you feel about telling generalist developers how to do crypto? My job is to find flaws in other people's code and then effectively exploit those flaws in front of them, and I certainly don't feel comfortable recommending implementations.

Incidentally, there's not much controversy about encrypt-then-MAC vs. mac-then-encrypt. You E-t-M, so attackers can't play games with ciphertext bits. Also: if you have the choice, you'd probably want to avoid using public key signatures when you could just get away with using a MAC. The public key stuff strictly adds vulnerabilities; it doesn't ameliorate any.

X-IstenceOP13y ago

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

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.

tptacek13y 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.

1 more reply

j / k navigate · click thread line to collapse