On Wednesday, 23 November 2016 10:50:37 CET Yoav Nir wrote: > On 23 Nov 2016, at 10:30, Nikos Mavrogiannopoulos <n...@redhat.com> wrote: > > On Wed, 2016-11-23 at 10:05 +0200, Yoav Nir wrote: > >> Hi, Nikos > >> > >> On 23 Nov 2016, at 9:06, Nikos Mavrogiannopoulos <n...@redhat.com> > > That to my understanding is a way to reduce > > latency in contrast to cpu costs. An increase to packet size targets > > bandwidth rather than latency (speed). > > Sure, but running ‘openssl speed’ on either aes-128-cbc or hmac or sha256 > (there’s no test for AES-GCM or ChaCha-poly) you get smallish differences > in terms of kilobytes per second between 1024-byte buffers and 8192-byte > buffers. And the difference going to be even smaller going to 16KB buffers, > let alone 64KB buffers.
this is not valid comparison. openssl speed doesn't use the hardware accelerated codepath you need to use `openssl speed -evp aes-128-gcm` to see it (and yes, aes-gcm and chacha20-poly1305 is supported then) What I see is nearly a 1GB/s throughput increase between 1024 and 8192 byte blocks for AES-GCM: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-gcm 614979.91k 1388369.31k 2702645.76k 3997320.76k 4932512.79k While indeed, for chacha20 there's little to no difference at the high end: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes chacha20-poly1305 242518.50k 514356.72k 1035220.57k 1868933.46k 1993609.50k 1997438.98k (aes-128-gcm performance from openssl-1.0.2j-1.fc24.x86_64, chacha20-poly1305 from openssl master, both on Intel(R) Core(TM) i7-6600U CPU @ 2.60GHz) -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
