Subject: Re: [openpgp] AEAD mode chunk size

From: "brian m. carlson" <[email-masked]>
Date: Sun, 1 Jul 2018 17:12:08 +0000

On Sat, Jun 30, 2018 at 06:00:40PM +0200, Marcus Brinkmann wrote:
> 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.

I agree with this.  The original specification I submitted limited the
value to something smaller for this reason.

> 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.

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

---

From: Marcus Brinkmann <[email-masked]>
Date: Sun, 1 Jul 2018 19:26:24 +0200

> value to something smaller for this reason.
...

> Of course, trailing chunks may be smaller, and that's okay; the document

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