On Thursday, February 28, 2019 10:39 AM, Jon Callas
<joncallas(_at_)icloud(_dot_)com> 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.
signature.asc
Description: OpenPGP digital signature
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp