ietf-openpgp
[Top] [All Lists]

Re: [openpgp] AEAD Chunk Size - Performance

2019-03-01 02:58:44
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.

_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp

<Prev in Thread] Current Thread [Next in Thread>
  • Re: [openpgp] AEAD Chunk Size - Performance, Neal H. Walfield <=