Discussion:
[openpgp] AEAD mode chunk size
Marcus Brinkmann
2018-06-30 16:00:40 UTC
Permalink
Hi,

RFC4880bis contains this segment:

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.

This allows chunk size up to 2^(6+56) = 4 EiB. It is impossible to
implement AEAD correctly with chunk sizes larger than can be buffered in
RAM. A large chunk size would require output of unverified plaintext,
enabling attacks like EFAIL but also others.

To implement AEAD correctly, chunk size must be limited to reasonable
sizes. TLS uses a chunk size up to 2^14 (16 KiB), but any reasonable
limit will do, for example 64 KiB. I suggest to change the text to this:

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)

An implementation MUST support chunk size octets with values from 0
to 16. Chunk size octets with other values are reserved for future
extensions.

Thanks,
Marcus Brinkmann
brian m. carlson
2018-07-01 17:12:08 UTC
Permalink
Post by Marcus Brinkmann
Hi,
The chunk size octet specifies the size of chunks using the following
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.
This allows chunk size up to 2^(6+56) = 4 EiB. It is impossible to
implement AEAD correctly with chunk sizes larger than can be buffered in
RAM. A large chunk size would require output of unverified plaintext,
enabling attacks like EFAIL but also others.
I agree with this. The original specification I submitted limited the
value to something smaller for this reason.
Post by Marcus Brinkmann
To implement AEAD correctly, chunk size must be limited to reasonable
sizes. TLS uses a chunk size up to 2^14 (16 KiB), but any reasonable
The chunk size octet specifies the size of chunks using the following
chunk_size = ((uint64_t)1 << c)
An implementation MUST support chunk size octets with values from 0
to 16. Chunk size octets with other values are reserved for future
extensions.
The reason I specified a lower bound of 64 bytes per chunk is that it
doesn't make sense to have chunks that are, for example, 1 byte long.
That's a great way to be wasteful and potentially DoS a recipient, since
each AEAD chunk involves some block cipher overhead.

Of course, trailing chunks may be smaller, and that's okay; the document
anticipates that.
--
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204
Marcus Brinkmann
2018-07-01 17:26:24 UTC
Permalink
Post by brian m. carlson
I agree with this. The original specification I submitted limited the
value to something smaller for this reason.
...
Post by brian m. carlson
The reason I specified a lower bound of 64 bytes per chunk is that it
doesn't make sense to have chunks that are, for example, 1 byte long.
That's a great way to be wasteful and potentially DoS a recipient, since
each AEAD chunk involves some block cipher overhead.
Of course, trailing chunks may be smaller, and that's okay; the document
anticipates that.
I'd be fine with having a lower limit as well, and if the best way to
express that is "2^(6+c) with 0 <= c <= 10" instead of "2^c with 6 <= c
<= 16" then that's fine with me, too.

I dug your original change, it can be found here:
https://gitlab.com/openpgp-wg/rfc4880bis/merge_requests/4/diffs

Here is your original wording for reference:

An implementation MUST support chunk size octets with values from 0
to 10. An implementation MAY support other chunk sizes. Chunk size
octets with values larger than 127 are reserved for future extensions.

Thanks!
Marcus

Loading...