Thread: I have just been in a discussion with @hanno and others, and think I should set out my thoughts about CBC, authenticated encryption, and signatures. 1/n
First, if you always check your HMACs, auth tags, signatures for correctness and that they are the ones you expect, then you can use either Encrypt-then-MAC, AEAD, or signatures and they will do what you need 2/n
The main difference will probably be speed, but from a purely authentication point of view, *if you do all the required checks*, there is no difference between Encrypt-then-MAC, AEAD, and signatures. 3/n
For example, it is claimed that MACs or AEADs are better than signatures because an attacker can sign a modified plaintext, something that's not possible with MACs or AEADs since they use the same key, so the auth tag check will fail. 4/n
That's true, but irrelevant. In the model above, everyone always does all the required checks. For signatures, that would be (a) validity of signature, (b) correctness of public key being used. For HMACs, that's (a) validity of HMAC, (b) authenticity of key. 5/n
So you have to do two checks either way and leaving any check out leaves you vulnerable to attacks. Now the next problem is: how easy is it to get any of this wrong? IMHO, way too easy, for any authentication scheme. 6/n
For example, remember Efail? In some circumstances, the encryption program said at the end of the decryption process that the ciphertext could not be authenticated, but the mail program had already acted on the deciphered plaintext and displayed that. 7/n
This is precisely what you get with AEAD: the auth tag is only computed at the end. But in the meantime, there is all this juicy plaintext lying around, and the temptation to use it will certainly be too much for some programmers. 8/n
As you may have noticed, none of the above has mentioned CBC, and for good reason: when it comes to authentication, CBC is a complete red herring, since CBC is for confidentiality, not authentication. The problem is not CBC, but not using authentication. 9/n
Now let's take a look at AEAD, since some people believe that it should preferentially be used over, e.g., signatures. Again, if implemented correctly, AEAD gives the same security guarantees as, e.g., CBC+HMAC, but is likely to be much faster. 10/n
But how easy is it to get anything wrong? With CBC, the classic problem is re-use of the IV. In CBC, this leads to identical plaintext prefixes being encrypted to identical ciphertexts. That's pretty bad. What happens when IV-equivalent material is reused in AEAD? 11/n
The most popular version of AEAD is GCM. That is a stream cipher. When you reuse key + IV in a stream cipher, you regenerate and hence reuse the key stream. Now let's compare CBC and GCM with respect to this reuse, shall we? 12/n
In CBC, you can see that two messages have the same prefix. If you have cribs, you may even be able to guess what these prefixes are. In GCM, you completely lose the protection from the keystream, since the XOR of the ciphertexts gives you the XOR of the plaintexts. 13/n
In other words, if GCM fails in the same way that CBC can fail through reuse of IV-equivalent material, it is as if no encryption at all had happened. In this way, GCM is much more brittle than CBC. 14/n
So, to summarise. 1. If done correctly, AEAD, Encrypt-then-MAC, and signatures give the same security guarantees w.r.t. authenticity. This always includes two checks: whether the authenticator is itself correct, and whether it comes from an expected source. 15/n
2. Additionally, all procedures require you to discard unauthenticated messages. If unauthenticated ciphertext is being acted upon, efail-like attacks are possible, no matter what authentication mechanism is being used. 16/n
3. Both CBC and GCM are vulnerable to IV-equivalent material being reused. In CBC, such reuse leads to identical plaintext prefixes being encrypted to identical ciphertext. In GCM it leads to complete loss of protection through encryption. 17/n
I have glossed over many details here. For example, I have said that, from an authentication perspective, AEAD, Encrypt-then-MAC, and signatures were "equivalent". Of course they are different, and have different properties in different situations. 18/n
For example, some may be useful for data-at-rest and others not. But my point is that you could, if you wanted, replace, e.g., AEAD with signatures, and get the same authentication properties even though from a practical perspective that would make little sense. 19/19 /ends
