[purple_elephant]

>In 2023, the way to use AES is AES-GCM. Anything else is very unlikely to make sense.

Encrypt-then-MAC remains the most conservative and theoretically secure option.

Leaving aside the (very serious) nonce reuse issue, the cracks on non-committing AEADs in general (such as AES-GCM) are already showing. Partitioning oracle attacks affect all of them: https://crypto.stackexchange.com/questions/88716/understandi...

There are also other minor GCM-specific issues (weak keys etc.). None of the issues are cypher-breaking, but I wouldn't say that AES-GCM is automatically the best choice for everything.

[tptacek]

GCM is an encrypt-then-MAC mode.

[some_furry]

And AES-GCM-SIV is MAC-then-Encrypt but is still secure (albeit not committing), so people cry foul when it's pointed out.

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

[fdupress]

Etam absolutely allows you to authenticate an unencrypted context. In fact, you must ensure that the nonce, a piece of unencrypted context, is authenticated. Nothing stops you from throwing more stuff in there.

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.

[some_furry]

> Etam absolutely allows you to authenticate an unencrypted context.

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.

[fdupress]

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

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.

[some_furry]

> This may expose a padding oracle, with all the nice attacks those things allow, depending on details of the application.

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. :)

[formerly_proven]

Maybe I'm missing something here or I'm just being dense but what exactly is the problem with EtM and AAD? Just use a suitable encoding like MAC(len(aad) || aad || E(plain))

[some_furry]

It's easy to say "just use a suitable encoding".

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.

[peppermint_gum]

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

That's very vague and therefore not very helpful. Could you say what exactly is wrong with the code you linked?

[soatok]

It does exactly what I've been describing!

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.

[nmadden]

Or better yet: https://neilmadden.blog/2021/10/27/multiple-input-macs/