On: I want XAES-256-GCM/11

[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 → formerly_proven]

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 → some_furry]

> 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 → peppermint_gum]

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 → formerly_proven]

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