Re: [openpgp] AEAD Chunk Size

[Bart Butler <[e-mail]>]

On Thursday, February 28, 2019 10:39 AM, Jon Callas <[e-mail]> wrote:

> 

> Implementations should pick a chunk size with care. Depending on the AEAD algorithm, large chunk sizes may limit the ability to process chunks, particularly with an AEAD algorithm that is not single-pass, and thus the system decrypting it must hold the entire chunk as it decrypts it. In general, the chunk size is irrelevant to any code outside of the chunk handling code, so smaller is better.
> 

> An implementation SHOULD pick a chunk size of 256KiB or less. An implementation MAY use larger sizes, but this could limit interoperability with resource-limited systems and should be done with care.
> 

> I don’t think that’s perfect, but it’s okay as a first draft. I would completely support something like the text above. I’d support it if it said 16KiB too. I’ll also support hard limits, but my intuition is that that decision will come with frustration for someone else.
> 

> Does this make more sense?
> 

> Jon

What do you think about this? I made the last sentence a bit scarier and introduces the lower recommendation as well:

Implementations should pick a chunk size with care. Depending on the AEAD algorithm, large chunk sizes may limit the ability to process chunks, particularly with an AEAD algorithm that is not single-pass, and thus the system decrypting it must hold the entire chunk as it decrypts it. Small chunk sizes may introduce unnecessary overhead in decryption. In general, the chunk size is irrelevant to any code outside of the chunk handling code.
 

An implementation SHOULD pick a chunk size between 16KiB and 256KiB (c between 8 and 12). An implementation SHOULD refuse to process chunks outside this size range in federated or untrusted contexts.