GCM is an encrypt-then-MAC mode.
AEADs are obviously better than EtM, because EtM doesn't allow for authenticating the unencrypted context.
I wrote about turning CTR+HMAC into a committing AEAD and promptly screwing it up badly: https://soatok.blog/2021/07/30/canonicalization-attacks-agai...
The only thing you can do with an integrated AEAD that you can't do with a constructed one (with standard interface and security) is include authenticated and unencrypted context halfway through an encryption.
You can specify an EtM construction that accepts additional authenticated data. However, you can also do it insecurely (as the post I linked above describes) without realizing you did it insecurely. This is why most people prefer to use cryptographer-approved AEAD modes.
> In fact, you must ensure that the nonce, a piece of unencrypted context, is authenticated.
For CBC mode, sure. For CTR mode? Not really.
> Nothing stops you from throwing more stuff in there.
What prevents an attacker from shifting bits from the ciphertext field into the AAD field in the decrypt path and yield the same HMAC tag? Unless you have an answer to this question, vanilla "encrypt then MAC" is not sufficient. You need a better-engineered construction than that.
I'm pretty sure the linked post covered all of this nuance. Please let me know if something wasn't clear, or you feel it was missing.
Sure, I agree with this. But then the advantage of AEAD over a bespoke EtM is not that AEAD allows the authentication of unencrypted context.
>> In fact, you must ensure that the nonce, a piece of unencrypted context, is authenticated.
> For CBC mode, sure. For CTR mode? Not really.
If you don't, you do not get ciphertext integrity: decryption will succeed, but mostly yield gibberish, if the adversary changes the nonce in a decryption query. This may expose a padding oracle, with all the nice attacks those things allow, depending on details of the application.
>> Nothing stops you from throwing more stuff in there.
> What prevents an attacker from shifting bits from the ciphertext field into the AAD field in the decrypt path and yield the same HMAC tag? Unless you have an answer to this question, vanilla "encrypt then MAC" is not sufficient. You need a better-engineered construction than that.
Yes, you need a well-engineered construction.
> Please let me know if something wasn't clear, or you feel it was missing.
And yes, your linked post covers all this, but that is not the point: your summary of the linked post just claims superiority of AEAD (which I took as integrated AEAD modes) over EtM because of a functionality you claim is missing from the latter. But in the same way you need a well-engineered integrated AEAD to get any kind of security, you will need a well-engineered Encrypt-then-MAC-with-AD construction to get a secure construction. And here "well-engineered" means "ensure unambiguous parsing of decryption inputs," we're not talking about high-flying stuff that doesn't have standard solutions.
In short: I accept the point of your linked post, and I agree with it. But I reject the claim that a functionality mismatch is what makes integrated AEAD better than a constructed EtM.
Please describe the padding oracle attack against AES-CTR you're envisioning.
> In short: I accept the point of your linked post, and I agree with it. But I reject the claim that a functionality mismatch is what makes integrated AEAD better than a constructed EtM.
Okay, I don't think we disagree then. We're just debating semantics at this point. :)
But when people say "use AES-CBC + HMAC" and cite Signal as an example, and Signal's implementation does this: https://github.com/signalapp/Signal-Android/blob/main/app/sr...
Well, when that happens, I feel the need to pipe in :)
If you're careful enough to not implement a naive protocol that stitches AES+CBC and HMAC-SHA2 together (or, as tptacek put it in a podcast episode, throw some crypto potions into a cauldron and see what happens), you're probably the minority of crypto-savvy people.
That's very vague and therefore not very helpful. Could you say what exactly is wrong with the code you linked?
They provide AE, not AEAD.
They feed an IV and ciphertext into HMAC. They don't feed additional authenticated data.
If someone followed Signal's example, they either wouldn't have AEAD, or they're likely to make the exact mistake described in the post I linked above.
I don't know how to be more helpful here. I've been only repeating myself.
AEAD modes let you bind a ciphertext to a context without increasing bandwidth. This is super important for database cryptography. Read more: https://soatok.blog/2023/03/01/database-cryptography-fur-the...
Whether "it's not AEAD" matters for an application depends on many factors. Signal doesn't need it.