Re: [openpgp] AEAD Chunk Size

["brian m. carlson" <[e-mail]>]

On Thu, Feb 28, 2019 at 10:39:17AM -0800, Jon Callas wrote:
> The best way to deal with it in a standard is to have non-normative guidance. It is non-normative guidance that I was suggesting. Let me write an example bit of non-normative guidance below:
> 
> - - - - -
> 
> 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.

I think this is a good first start. However, I think we need to specify
some guidelines about what sizes are required for interoperability. I'm
happy to give people guidance, but if we state that chunk sizes up to
256 KiB (or whatever size we decide) are required to be supported, then
we let people decide whether performance or interoperability is more
important for their use case.

So I'd specify a sentence at the beginning of the second paragraph that
says, "An implementation MUST support chunk sizes up to 256 KiB."
-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204