Re: [TLS] record layer limits of TLS1.3

[Hubert Kario <[e-mail]>]

On Wednesday, 23 November 2016 10:50:37 CET Yoav Nir wrote:
> On 23 Nov 2016, at 10:30, Nikos Mavrogiannopoulos <[e-mail]> wrote:
> > On Wed, 2016-11-23 at 10:05 +0200, Yoav Nir wrote:
> >> Hi, Nikos
> >> 
> >> On 23 Nov 2016, at 9:06, Nikos Mavrogiannopoulos <[e-mail]>
> > 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