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