Re: [openpgp] AEAD Chunk Size - Performance

["Neal H. Walfield" <[e-mail]>]

At Thu, 28 Feb 2019 19:11:06 +0000,
Bart Butler wrote:
> "Re. Neal's request, I didn't have the numbers anymore, so I unscientifically created some new ones
> 
> It looks like either Chrome or we have actually fixed the performance issues there with c=8 since the last time I tested it, as for most message sizes the performance is the same as c=12 or even a bit faster, except 128KB-256KB, which fits in one chunk with c=12 and there c=8 is about 1.1x - 1.5x slower.
> 
> In Firefox, for >=64KB messages, c=8 is still about 1.5x - 2.5x slower than c=12, however, it looks like most of the overhead of smaller chunks comes from the streams polyfill, not the web crypto API. So that should probably be possible for us to fix."

Thanks for providing these numbers!  It's particularly interesting to
hear how the performance has changed over time.

> I see your logic on 16 kiB but in particular for file encryption I think there's some value to being able to go bigger in the future (L2 cache sizes have changed in the last 20 years as well and will probably change in the next two decades), and to keep the size byte to be able to configure this rather than have an entirely new packet. I think a SHOULD for 16 kiB though is totally appropriate now though for the reasons you mentioned.

Although I have a slight preference for 16 kiB due to performance
concerns, my first priority is security.  I'd like, at the minimum, a
hard ceiling, but I'd prefer no chunk size parameter at all.  I
appreciate backwards compatibility, and I'm willing to go with
renaming "chunk size" to "magic value" and fixing that to the C
corresponding to 256 kiB chunks.