# What might be the intuition for this scheme to be AEAD and what is the problem with this?

There is a plaintext message $M$, and a key $K \:\stackrel{{\scriptscriptstyle \hspace{0.2em}\$}} {\leftarrow}\ \{0,1\}^{128}$which we will use for AES, we can extract a ciphertext$C \gets \mathrm{CBC}[\mathrm{AES}_K](0^n,M)$, i.e., CBC mode encryption under IV$0^n$of the message. The master keys$L1,L2$are shared between the sender and receiver. Sender creates a header (associated data)$H$that contains various things including a ciphertext$W \gets \mathrm{AES}_{L1}(K)$, the enciphering of the per-message key$K$under master key$L1$. Sender also computes a tag$T \gets F_{L2}(H)$for some function family$F$that we assume is a good PRF. Then the sender transmits$(H,T,C)$to the receiver. • How would this scheme authenticate the ciphertext$C$? It seems to only authenticate the header, not the ciphertext. Since the IV is the same for every message, the message key$K$must be unique across all messages. Why change the key rather than changing the IV as prescribed by CBC? – knbk Mar 12 '17 at 20:01 • @knbk we have to change the key. Let's suppose key is unique per message then is there any problem in tag generation and cipher text computation.As long as key is used per-message cipher text generation will be fine.But tag is generated by taking PRF of header and header consists of AES encryption of key K and some random text. Mar 12 '17 at 21:02 • @knbk this is my understanding. Please correct me if I'm wrong. Mar 12 '17 at 21:09 ## 1 Answer A critical part of any AEAD scheme is that it ensures the authenticity of the header data and the ciphertext. Your scheme only protects the header data, leaving the ciphertext vulnerable. Protecting the key is not enough. CBC mode is affected by certain bit-flipping attacks, that allows an attacker to change part of the message. This results in one block being completely garbled, and the next block having the exact bits flipped that were flipped in the attack. The rest of the decrypted message is untouched. If you don't authenticate the ciphertext, you will be vulnerable to this attack. This attack also extends to certain padding oracle attacks. As for the IV and key: using a static IV with a unique per-message key may be secure, but it's a non-standard way of implementing CBC. Best case, it doesn't gain you anything over the standard way of implementing CBC. In the spirit of "Don't roll your own", it would be best to use CBC the standard way, with a random, unique and unpredictable IV. • Thanks for your response! Suppose we implement CBC the standard way, is the tag generation part fine, as the tag is generated as F(W || <H'>) where H' is the part of the header excluding ciphertext W? Isn't the repetition of H' going to compromise the authenticity of the tag T? Mar 12 '17 at 22:38 • @mogambo The tag still wouldn't cover the ciphertext$C$, so the authenticity of$C\$ would in no way be guaranteed.
– knbk
Mar 12 '17 at 22:50