[Top] [All Lists]

Re: [openpgp] AEAD Chunk Size

2019-02-27 17:00:36
Hi Jon,

Do I understand correctly that you oppose shrinking the allowable range with 
MUST at all too? I think the argument for this is fairly convincing from a 
usage perspective to ensure that someone decrypting a large message is not 
obligated to download a huge amount of data before finding out that it is 
corrupted or otherwise has been tampered with. Likewise, we had to address 
unanticipated performance issues in OpenPGP.js with very small chunks which 
could have allowed a bad actor to essentially DoS the library with a 
strangely-constructed message.

In other words, I'm not really swayed by the implementation simplification 
argument but I do think that very small or very large chunk size, in addition 
to *probably* being useless, pose a real threat in terms of abuse.

So I think having a MUST for the range, maybe 16kiB to 256 kiB, or 16 kiB to 
1024 kiB is a reasonable thing to do. And as long as we keep the size byte, we 
can always increase the upper limit of the range in the future if needed.


‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday, February 27, 2019 2:37 PM, Jon Callas 
<joncallas(_at_)icloud(_dot_)com> wrote:

On Feb 27, 2019, at 1:34 PM, Bart Butler 
bartbutler=40protonmail(_dot_)com(_at_)dmarc(_dot_)ietf(_dot_)org wrote:
Hi all,
We (Sunny Rajan and I) definitely agree with reducing the range of allowed 
sizes, because both 4 exabyte chunks and large messages composed of 64-byte 
chunks are clearly not optimal.
In our AEAD implementation for OpenPGP.js we settled on a default `c` of 12 
rather than 8 after some performance benchmarking showed that 256 kiB 
chunks were more performant for the most common message sizes. Our result 
was specific to the web crypto API, and therefore specific to OpenPGP.js, 
but in general libraries may want to use different default sizes depending 
on implementation details like this.
So ideally we’d prefer to keep the size byte, but to shrink its range in 
both directions. For example, the RFC could state that the chunk SHOULD be 
16 kiB (or 256 kiB, hint hint), but decryption MUST be available for `c` 
values between 8-12 inclusive. This would also allow us to be 
backwards-compatible with messages that have already been created following 
the current version of the draft, which do exist given the benefit that 
AEAD provides and that OpenPGP.js has supported the current draft in 
experimental mode for most of the last year.

I think this is a reasonable way to have it to put an upper limit with a 

I believe that if we limit it to 16K, we will regret that, for performance or 
other reasons. And while some of the upper sizes are presently absurdly 
large, one never knows what happens a couple decades from now.

Moreover, forbidding it says that we state now that no one could ever have a 
reasonable use; my experience is that categorical statements like that are 
just asking the fates to bite us in an uncomfortable place. Amazon S3 
increased their max object size to 5TB a few years ago. I’m not saying it 
should be that large, but I think this is a pretty convincing argument that 
16K is too small.

So I think that a SHOULD is the right way to put it. I care less about what 
the SHOULD limit should be, but a small hard limit sounds like a bad idea.


Attachment: signature.asc
Description: OpenPGP digital signature

openpgp mailing list