Module sequoia_openpgp::packet::aed

AEAD encrypted data packets.

An encryption container using Authenticated Encryption with Additional Data.

The AED packet is a new packet specified in Section 5.16 of RFC 4880bis. Its aim is to replace the SEIP packet, whose security has been partially compromised. SEIP’s weaknesses includes its use of CFB mode (e.g., EFAIL-style CFB gadgets, see Section 5.3 of the EFAIL paper), its use of SHA-1 for integrity protection, and the ability to downgrade SEIP packets to much weaker SED packets.

Although the decision to use AEAD is uncontroversial, the design specified in RFC 4880bis is. According to RFC 5116, decrypted AEAD data can only be released for processing after its authenticity has been checked:

[The authenticated decryption operation] has only a single output, either a plaintext value P or a special symbol FAIL that indicates that the inputs are not authentic.

The controversy has to do with streaming, which OpenPGP has traditionally supported. Streaming a message means that the amount of data that needs to be buffered when processing a message is independent of the message’s length.

At first glance, the AEAD mechanism in RFC 4880bis appears to support this mode of operation: instead of encrypting the whole message using AEAD, which would require buffering all of the plaintext when decrypting the message, the message is chunked, the individual chunks are linked together, and AEAD is used to encrypt and protect each individual chunk. Because the plaintext from an individual chunk can be integrity checked, an implementation only needs to buffer a chunk worth of data.

Unfortunately, RFC 4880bis allows chunk sizes that are, in practice, unbounded. Specifically, a chunk can be up to 4 exbibytes in size. Thus when encountering messages that can’t be buffered, an OpenPGP implementation has a choice: it can either release data that has not been integrity checked and violate RFC 5116, or it can fail to process the message. As of 2020, GnuPG and RNP process unauthenticated plaintext. From a user perspective, it then appears that implementations that choose to follow RFC 5116 are impaired: “GnuPG can decrypt it,” they think, “why can’t Sequoia?” This creates pressure on other implementations to also behave insecurely.

Werner argues that AEAD is not about authenticating the data. That is the purpose of the signature. The reason to introduce AEAD is to get the benefits of more modern cryptography, and to be able to more quickly detect rare transmission errors. Our position is that an integrity check provides real protection: it can detect modified ciphertext. And, if we are going to stream, then this protection is essential as it protects the user from real, demonstrated attacks like EFAIL.

RFC 4880bis has not been finalized. So, it is still possible that the AEAD mechanism will change (which is why the AED packet is marked as experimental). Despite our concerns, because other OpenPGP implementations already emit the AEAD packet, we provide experimental support for it in Sequoia.

Structs

• AED1
  Holds an AEAD encrypted data packet.