12.2: Achieving AE/AEAD
- Page ID
- 7370
The Encrypt-then-MAC construction (Construction 10.9) has the property that the attacker cannot generate ciphertexts that decrypt correctly. Even though we introduced encrypt-then-MAC to achieve CCA security, it also achieves the stronger requirement of AE.
If E has CPA security and \(M\) is a secure \(M A C\), then EtM (Construction 10.9) has AE security.
- to-do
-
There is a slight mismatch here, since I dened AE/AEAD security as a “pseudorandom ciphertexts” style definition. So you actually need CPA$+PRF instead of CPA+MAC. But CPA+MAC is enough for the left-vs-right style of AE/AEAD security.
Encrypt-then-MAC with Associated Data
Recall that the encrypt-then-MAC construction computes a MAC of the ciphertext. To incorporate associated data, we simply need to compute a MAC of the ciphertext along with the associated data.
Recall that most MACs in practice support variable-length inputs, but the length of the MAC tag does not depend on the length of the message. Hence, this new variant of encrypt-then-MAC has ciphertexts whose length does not depend on the length of the associated data.
If E has CPA security and \(M\) is a secure \(M A C\), then Construction \(12.4\) has AEAD security, when the associated data has fixed length (i.e., \(\mathcal{D}=\{0,1\}^{n}\) for some fixed \(n\) ).
- to-do
-
This construction is insecure for variable-length associated data. It is not terribly hard to x this; see exercises