Skip to content

Fix the AEAD chunk size to 16 kiByte.

Neal H. Walfield requested to merge nwalfield/rfc4880bis:neal/fix-the-aead-chunk-size-to-16-kibyte into master

See https://mailarchive.ietf.org/arch/msg/openpgp/XH098WlJe8lkOypIaB1IXTde2sY

The current version of 4880bis has a chunk size parameter for AEAD:

AEAD Encrypted Data Packet (Tag 20)

...

The body of this packet consists of:

...

* A one-octet chunk size.

...

The chunk size octet specifies the size of chunks using the following formula (in C), where c is the chunk size octet:

   chunk_size = ((uint64_t)1 << (c + 6))

An implementation MUST support chunk size octets with values from 0 to 56. Chunk size octets with other values are reserved for future extensions. Implementations SHOULD NOT create data with a chunk size octet value larger than 21 (128 MiB chunks) to facilitate buffering of not yet authenticated plaintext.

https://tools.ietf.org/html/draft-ietf-openpgp-rfc4880bis-05#section-5.16

In other words, chunks can be up to 1 << (56 + 6) = 2^62 bytes large (4 exbibytes).

According to RFC 5116, an AEAD algorithm must not output partially decrypted data:

If a particular implementation of an AEAD algorithm is requested to process an input that is outside the range of admissible lengths, or an input that is outside the range of lengths supported by that implementation, it MUST return an error code and it MUST NOT output any other information. In particular, partially encrypted or partially decrypted data MUST NOT be returned.

https://tools.ietf.org/html/rfc5116#section-2.1

Because it is hard to know the context (i.e., the available resources) in which a message will be decrypted, it is difficult for an implementation to make a reasonable choice when doing the encryption. Actually, I'm not aware of any advantages for chunk sizes that are larger than a few kilobytes.

Consequently, I propose not only imposing a reasonable ceiling on the chunk size that even small embedded devices with a cortex M0 could handle, but to simply fix the parameter to 16 KiB. It's not clear to me that a variable size offers any advantages. But, there is a clear disadvantage: it's unjustified complexity, which is a breeding ground for bugs. Unless someone can justify this added complexity, I see no reason to parameterize this.

(If it is needed, the size could be a function of the actually AEAD algorithm, e.g., EAX, OCB, etc.)

I've attached a patch that makes the proposed change.

I've spoken with several people including Vincent Breitmoser (Open Keychain), Justus Winter & Kai Michaelis (also Sequoia), Phil Zimmermann, and Hanno Böck and they all support this proposal.

Merge request reports