3 ms·

I applaud the person who put this together but my humble opinion is that there are a lot of assumptions here. There are many situations (few I habe encountered

by _8j50 4y ago

I applaud the person who put this together but my humble opinion is that there are a lot of assumptions here. There are many situations (few I habe encountered first hand) where you need to break the rules and how you break the rules also have best practices that should be mentioned. Some items that stood out for me after a skim: - AES-CBC is not unusable, from what I understand with random IV and a good HMAC it is usable? - "Really, anything RSA", there are protocols that encrypt the key with RSA for key transport and use AES or some other block cipher for the data. As far as I am aware this is safe given the key is derived properly and is not reused. If you have to encrypt using their public key and you are restricted from using EC anything your choices are few. - Custom transport protocols are sometimes needed. TLS is general purpose which means there are corner cases it can't support once in a whole and you can't always use noise. What are best practices to implement key exchange, manage keys and authentication+integrity? My feed back is that often people are lazy enough to use a pre-made library but when they can't telling them there is no alternative does not help. But otoh, I get that perhaps going into such detail would make the content of the gist too long.

opheliate 4y ago
AES-CBC with a random IV and solid HMAC should be fine, but the point is that, for a non-cryptographer, putting together an authenticated encryption construction yourself has potential footguns. Using a pre-made authenticated encryption construction like AES-GCM or Salsa20-Poly1305 avoids this. Any platform with hardware acceleration for AES should hopefully have a carryless multiplication instruction anyway, so GCM will be fast. And if not, Poly1305 is so fast that another HMAC construction will perform worse. So there’s really no reason not to just use one of these two in 99% of cases.
- _8j50 4y ago
  I agree that when you have a choice it should be done as you said. I am not even a developer and I've been in situations where aes-gcm or poly1305 (or ed25519 and other popular curves) were availabe. Sometimes it is b.s. internal politics, other times it is third parties that can "only" use a certain set of tools or dependencies and it is either come up with something custom or lose the deal/contract.
unscaled 4y ago
The main issue with AES-CBC+HMAC (besides speed), is that unless you're using a library that offers a complete primitive that combines these algorithms[1], you will have to combine the encryption and MAC yourself. In this case, you will have to know, that the only safe way to do this with is Encrypt-then-MAC, and you'll also have to remember to do (and in some languages know how to implement!) a constant-time comparison for the HMAC value. Since it's highly unlikely than an untrained developer will do all of these correctly, the authors are right, IMHO, to avoid mentioning AES-CBC+HMAC. Yes, it can be implemented safely. So does RSA for that matter. But is it likely that most developers (or let's be generous - even more than 10% of them) will implement this correctly? No. When you need to roll your own crypto (custom transports, RSA combos for compatibility reasons) you'll just have to get an expert to do that. WireGuard implements its own transport and TarSnap implements its own crypto (on top of RSA, no less!) and you don't see the authors of these documents criticizing them. In fact, TarSnap is consistently recommended in this guide. But the audience for these best practices is not Colin Percival[2]. It's the average developer who usually has an "Intro to Cryptography" background from their CS Major at the best of times. [1] I am not aware of any audited library that does this, but Google's Tink offers AES-CTR+HMAC: https://developers.google.com/tink https://developers.google.com/tink [2] https://en.wikipedia.org/wiki/Colin_Percival https://en.wikipedia.org/wiki/Colin_Percival
- _8j50 4y ago
  > Since it's highly unlikely than an untrained developer will do all of these correctly, the authors are right Oh come on! It's not rocket science, just encrypt and hmac. My point was mentioning that best practicr tip for example will help. People still use aes-ecb because they don't know failing with aes-cbc is better. > When you need to roll your own crypto (custom transports, RSA combos for compatibility reasons) you'll just have to get an expert to do that If someone is in a position where they're choosing ciphers and they're not an expert, chances are they won't get funds to hire an expert and they can't tell their boss or customer they can't do it. Help people not shoot their own foot off is all I am saying. I agree with the audience part. The average dev also does not work in silicon valley or in a FAANG. They work in bigcorp,consulting or government where you do your best with unreasonable requirements and little cash to spare for third party experts.

by _8j50 4y ago

opheliate 4y ago

AES-CBC with a random IV and solid HMAC should be fine, but the point is that, for a non-cryptographer, putting together an authenticated encryption construction yourself has potential footguns. Using a pre-made authenticated encryption construction like AES-GCM or Salsa20-Poly1305 avoids this. Any platform with hardware acceleration for AES should hopefully have a carryless multiplication instruction anyway, so GCM will be fast. And if not, Poly1305 is so fast that another HMAC construction will perform worse. So there’s really no reason not to just use one of these two in 99% of cases.

_8j50 4y ago
I agree that when you have a choice it should be done as you said. I am not even a developer and I've been in situations where aes-gcm or poly1305 (or ed25519 and other popular curves) were availabe. Sometimes it is b.s. internal politics, other times it is third parties that can "only" use a certain set of tools or dependencies and it is either come up with something custom or lose the deal/contract.

unscaled 4y ago

The main issue with AES-CBC+HMAC (besides speed), is that unless you're using a library that offers a complete primitive that combines these algorithms[1], you will have to combine the encryption and MAC yourself. In this case, you will have to know, that the only safe way to do this with is Encrypt-then-MAC, and you'll also have to remember to do (and in some languages know how to implement!) a constant-time comparison for the HMAC value. Since it's highly unlikely than an untrained developer will do all of these correctly, the authors are right, IMHO, to avoid mentioning AES-CBC+HMAC. Yes, it can be implemented safely. So does RSA for that matter. But is it likely that most developers (or let's be generous - even more than 10% of them) will implement this correctly? No. When you need to roll your own crypto (custom transports, RSA combos for compatibility reasons) you'll just have to get an expert to do that. WireGuard implements its own transport and TarSnap implements its own crypto (on top of RSA, no less!) and you don't see the authors of these documents criticizing them. In fact, TarSnap is consistently recommended in this guide. But the audience for these best practices is not Colin Percival[2]. It's the average developer who usually has an "Intro to Cryptography" background from their CS Major at the best of times. [1] I am not aware of any audited library that does this, but Google's Tink offers AES-CTR+HMAC: https://developers.google.com/tink https://developers.google.com/tink [2] https://en.wikipedia.org/wiki/Colin_Percival https://en.wikipedia.org/wiki/Colin_Percival

_8j50 4y ago
> Since it's highly unlikely than an untrained developer will do all of these correctly, the authors are right Oh come on! It's not rocket science, just encrypt and hmac. My point was mentioning that best practicr tip for example will help. People still use aes-ecb because they don't know failing with aes-cbc is better. > When you need to roll your own crypto (custom transports, RSA combos for compatibility reasons) you'll just have to get an expert to do that If someone is in a position where they're choosing ciphers and they're not an expert, chances are they won't get funds to hire an expert and they can't tell their boss or customer they can't do it. Help people not shoot their own foot off is all I am saying. I agree with the audience part. The average dev also does not work in silicon valley or in a FAANG. They work in bigcorp,consulting or government where you do your best with unreasonable requirements and little cash to spare for third party experts.