3 ms·

>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

>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/understanding-the-impact-of-partitioning-oracle-attacks-on-stream-ciphers 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 3y ago
GCM is an encrypt-then-MAC mode.
- some_furry 3y ago
  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-against-macs-and-signatures/ https://soatok.blog/2021/07/30/canonicalization-attacks-agai...
  - fdupress 3y ago
    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 3y ago
      > 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 3y ago
        > 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.
  - formerly_proven 3y ago
    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 3y ago
      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/src/main/java/org/thoughtcrime/securesms/crypto/MasterCipher.java#L159-L176 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 3y ago
        > 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/src/main/java/org/thoughtcrime/securesms/crypto/MasterCipher.java#L159-L176 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 3y ago
        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-rest-of-us/ 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.

tptacek 3y ago

GCM is an encrypt-then-MAC mode.

some_furry 3y ago
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-against-macs-and-signatures/ https://soatok.blog/2021/07/30/canonicalization-attacks-agai...
- fdupress 3y ago
  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 3y ago
    > 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 3y ago
      > 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.
- formerly_proven 3y ago
  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 3y ago
    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/src/main/java/org/thoughtcrime/securesms/crypto/MasterCipher.java#L159-L176 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 3y ago
      > 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/src/main/java/org/thoughtcrime/securesms/crypto/MasterCipher.java#L159-L176 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 3y ago
        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-rest-of-us/ 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.