ietf-openpgp
[Top] [All Lists]

Re: [openpgp] AEAD Chunk Size

2019-02-28 18:27:17
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

Attachment: signature.asc
Description: PGP signature

_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp
<Prev in Thread] Current Thread [Next in Thread>