Introduction

Most of the time, confidentiality is not enough - it needs to be combined with integrity in order for an application to be secure. So, even if an encryption scheme is CCA-secure, there is still room for ciphertext forgery. This necessitates even stronger security notions which are satisfied by authenticated encryption schemes.

Definition: Authenticated Encryption (AE-Security)

A cipher is an authenticated encryption scheme or is AE-secure if it is CPA-secure and provides ciphertext integrity (CI).

AE-security is the most widely adopted security notion and is ubiquitous in web applications. It is stronger than CCA-security - the constructs which satisfy AE-security also satisfy CCA-security. However, there is no real efficiency difference between ciphers which are AE-secure and ciphers which are only CCA-secure.

Theorem: AE-Security implies CCA-Security

Every AE-secure cipher is also CCA-secure.

This explains why ciphers which are only CCA-secure are rarely used in practice - why would you opt for less security when there is not even an efficiency benefit?

Implementation

There are many ways to implement authenticated encryption. Some include combining a CPA-secure cipher with a secure

Construction from a Cipher and a MAC

AE-secure encryption schemes can be constructed by combining a CPA-secure cipher with a CMA-secure message authentication code system . Such approaches use two separate keys - for encryption / decryption and for message signing and verification. These keys must be independent of each other.

However, it turns out that not all ways of combining these two systems yield an authenticated encryption and even if the correct approach is used, the keys and must still be completely independent, lest AE-security is broken.

Encrypt-and-Sign

In this approach, encryption and message signing are carried out independently from each other and in parallel. The supposedly AE-secure cipher is constructed by encrypting the message with some encryption function to produce a ciphertext . The message is also separately signed by the MAC and the resulting tag is appended to .

The final ciphertext is the concatenation of and the message tag , i.e.

To decrypt the ciphertext , the decryption function first parses it back into a message ciphertext and a message tag . It then decrypts the ciphertext using to obtain the message . Finally, it verifies the decrypted message with the tag . If the message is valid, then it is returned. Otherwise, an error is produced.

This is certainly a good attempt at constructing an authenticated encryption but it fails horribly.

WARNING

The Encrypt-and-Sign approach is not AE-secure.

Since the message is signed directly before being encrypted, nothing is stopping the tag from leaking information about it (CMA-secure MACs provide no secrecy guarantees). For example, a MAC might be CMA-secure but have tags whose first bit is always identical to the first bit of the message. This means that the Encrypt-and-Sign method might not even be semantically security.

Moreover, it is not CPA-secure because deterministic MACs will produce the same tag when given the same message, provided that the same signing key is used. This is a real concern, since most MAC systems used in practice are deterministic.

Sign-then-Encrypt

In this approach the first step is to compute the tag of the message , i.e. . It is then appended to the message and the resulting concatenation is what actually gets encrypted to obtain the ciphertext .

The decryption function decrypts the ciphertext to obtain the concatenation of the message with the tag and then verifies them. If either or validation result in an error, then simply errors out.

WARNING

The Sign-then-Encrypt approach may be AE-secure, but this depends highly on the specifics of the cipher and the MAC used. Since it does not provide AE-security in the general case of an arbitrary cipher and an arbitrary MAC, it should be avoided - there is simply too much room for mistakes when implementing it.

For example, if there are different error types depending on whether validation or decryption fails, something which is very much necessary in practice, then the security of this approach can be broken by padding oracle attacks.

Encrypt-then-Sign

This approach requires a MAC system with strong unforgeablity. First, the message is encrypted. The resulting ciphertext is then signed and the tag is appended to it to obtain the final ciphertext.

The decryption function parses the ciphertext back into a message ciphertext and a ciphertext tag . If ciphertext verification fails, then it returns an error. Otherwise, it returns the decryption of .

This approach is quite similar to Encrypt-and-Sign, but the tag is computed on the ciphertext instead of the plaintext. This small difference turns out to be crucial as it is what makes Encrypt-then-Sign AE-secure. Since the tag is verifying the ciphertext, no adversary can tamper with it. This reduces any CCA adversary to a CPA adversary and the CPA-security of guarantees protection against this.

It is paramount that the MAC system used has strong unforgeability. Otherwise, a CCA adversary challenged with a ciphertext can generate a new valid tag for with non-negligible probability. Since , the adversary is allowed to submit this new tag with to its decryption oracle which will pass verification. The decryption oracle will then hand the exact decryption of to the adversary and so they will know for sure if was the encryption of some message or another message . This would be a breach of CCA-security and therefore also a breach of AE-security.