4 ms·

The author takes the following statement to be incorrect: > I had written code for a constant-time text comparison of the MAC but then realized that this is no

The author takes the following statement to be incorrect: > I had written code for a constant-time text comparison of the MAC but then realized that this is not an issue when using the MAC-then-encrypt method because the MAC is only compared after decryption to verify that the data is intact and the same as when it was encrypted. Since the correct MAC is only exposed when the correct encryption key is used it doesn’t matter whether the text comparison is done in constant-time or not. Changing to an encrypt-then-MAC method (requiring a constant-time MAC comparison) would not be backwards compatible with the current version. I don't see anything wrong with this statement. With encrypt-then-MAC the application is going to calculate the MAC on the ciphertext then compare it against the MAC included with the ciphertext. If the two match then the application will decrypt the ciphertext into plaintext. If the attacker doesn't actually know the encryption key then the data will be garbled but that might not matter for certain attacks. The key to the attack is getting the MAC correct and to do that timing attacks on the comparison can be done. But in this case we are using MAC-then-encrypt. The application is going to decrypt the ciphertext to produce plaintext and MAC. Every time the attacker changes the ciphertext both the MAC and the plaintext will change unpredictably. Even with the timing leak, the attacker can't do anything with the ciphertext to make it such that the MAC verifies the plaintext One of the key flaws of modern security protocols is making them robust to bad implementations and side channels. I don't see the problem as being reasoning by Lego but rather in neglecting that the information you wish to protect is not just in the ciphertext, it can leak out into everything, the length of the message, padding, MAC, timing...

Nursie 6y ago
> If the attacker doesn't actually know the encryption key then the data will be garbled That depends on exactly what sort of cipher scheme is used. I don't know what exact scheme we're talking about here (it wasn't described in the post and I didn't go hunting any further) but there are stream constructions where if you change a bit in the ciphertext, it changes a corresponding bit in the plaintext that comes out. This is because in these modes the keystream is independent of the data and the ciphertext is the result of XORing the keystream with the plaintext. The plaintext is unrecoverable without the key, but what's decoded can be manipulated, even without knowing what it is. Mac-then-encrypt is definitely a problem in that circumstance. Encrypt-then-Mac is better in that it protects you from even decrypting anything before you've authenticated the source. > it can leak out into everything, ... MAC, timing... A good MAC algorithm doesn't leak anything about the plaintext. A good mac-checking algorithm doesn't give anything away with timing either. (edited to remove references to CFB, my memory of that stream construction was inaccurate, but the point in general stands, if I can manipulate some of the ciphertext that make known-changes to the plaintext decryption, I'm back to being able to make a timing analysis on MAC checking. It's better to check the MAC first, and in constant time.)
- just-ok 6y ago
  > A good MAC algorithm doesn't leak anything about the plaintext. Though this may be true for specific MAC algorithms, it's a very dangerous and incorrect assumption to hold in general. MACs are designed for integrity and nothing more.
  - Nursie 6y ago
    Fair enough, also not really at issue when we're talking about encrypt-then-mac I guess.
    - just-ok 6y ago
      Yep! Absolutely true, and one of the reasons why Encrypt-then-MAC is the only generic composition method scheme that always provides certain security properties (specifically, security against chosen-ciphertext attacks given that the "encrypt" part is secure against chosen-plaintext attacks and the "MAC" part is secure against forgeries).
tialaramex 6y ago
> Every time the attacker changes the ciphertext both the MAC and the plaintext will change unpredictably. No. This system uses CBC so changes to the ciphertext have predictable consequences for some of the plaintext including the MAC. This is why padding oracle attacks on CBC work so nicely. You smash a random byte you don't care about in block N-1 and twiddle a byte in block N. The padding oracle tells you if you got that byte "right" by the padding rules and so you can deduce what it was before you twiddled it.
- barbegal 6y ago
  > This system uses CBC so changes to the ciphertext have predictable consequences for some of the plaintext including the MAC. Specifically they have predictable consequences for the next block so if the MAC is at the end of the Nth block you can change the ciphertext of block N-1. You still have the problem that this changes both the plaintext and the MAC so the attack would still fail. Or so I thought until I read through https://gist.github.com/defuse/0822a9c6d70ab4939c95 https://gist.github.com/defuse/0822a9c6d70ab4939c95 to understand the attack. The MAC here fills at least a whole block allowing independent changes to the MAC and the plaintext.

Nursie 6y ago

> If the attacker doesn't actually know the encryption key then the data will be garbled That depends on exactly what sort of cipher scheme is used. I don't know what exact scheme we're talking about here (it wasn't described in the post and I didn't go hunting any further) but there are stream constructions where if you change a bit in the ciphertext, it changes a corresponding bit in the plaintext that comes out. This is because in these modes the keystream is independent of the data and the ciphertext is the result of XORing the keystream with the plaintext. The plaintext is unrecoverable without the key, but what's decoded can be manipulated, even without knowing what it is. Mac-then-encrypt is definitely a problem in that circumstance. Encrypt-then-Mac is better in that it protects you from even decrypting anything before you've authenticated the source. > it can leak out into everything, ... MAC, timing... A good MAC algorithm doesn't leak anything about the plaintext. A good mac-checking algorithm doesn't give anything away with timing either. (edited to remove references to CFB, my memory of that stream construction was inaccurate, but the point in general stands, if I can manipulate some of the ciphertext that make known-changes to the plaintext decryption, I'm back to being able to make a timing analysis on MAC checking. It's better to check the MAC first, and in constant time.)

just-ok 6y ago
> A good MAC algorithm doesn't leak anything about the plaintext. Though this may be true for specific MAC algorithms, it's a very dangerous and incorrect assumption to hold in general. MACs are designed for integrity and nothing more.
- Nursie 6y ago
  Fair enough, also not really at issue when we're talking about encrypt-then-mac I guess.
  - just-ok 6y ago
    Yep! Absolutely true, and one of the reasons why Encrypt-then-MAC is the only generic composition method scheme that always provides certain security properties (specifically, security against chosen-ciphertext attacks given that the "encrypt" part is secure against chosen-plaintext attacks and the "MAC" part is secure against forgeries).

tialaramex 6y ago

> Every time the attacker changes the ciphertext both the MAC and the plaintext will change unpredictably. No. This system uses CBC so changes to the ciphertext have predictable consequences for some of the plaintext including the MAC. This is why padding oracle attacks on CBC work so nicely. You smash a random byte you don't care about in block N-1 and twiddle a byte in block N. The padding oracle tells you if you got that byte "right" by the padding rules and so you can deduce what it was before you twiddled it.

barbegal 6y ago
> This system uses CBC so changes to the ciphertext have predictable consequences for some of the plaintext including the MAC. Specifically they have predictable consequences for the next block so if the MAC is at the end of the Nth block you can change the ciphertext of block N-1. You still have the problem that this changes both the plaintext and the MAC so the attack would still fail. Or so I thought until I read through https://gist.github.com/defuse/0822a9c6d70ab4939c95 https://gist.github.com/defuse/0822a9c6d70ab4939c95 to understand the attack. The MAC here fills at least a whole block allowing independent changes to the MAC and the plaintext.