Re: Packet number encryption

[Mikkel Fahnøe Jørgensen <[e-mail]>]

To put numbers into perspective using Intel 2015 data

https://software.intel.com/en-us/articles/improving-openssl-performance#_Toc416943490

A 64 byte message in AES-GCM AEAD in HW would use 1.03 cycles per byte or
66 cycles total, or 22ns on a 3GHz core.

For packet numbers we use the CBC encrypt numbers because here AES cannot
exploit block parallelism.
Here we see 4.44 cycles/byte in HW or 71 cycles per block. With a 3GHz
setup that would amount to about 24ns overhead for packet encryption.

Clearly it makes no sense that AES-GCM is faster than a single AES block
encryption, but these are only approximate numbers and CBC mode might have
a little overhead, so we clamp packet numbers to 22ns.

Taking the 98ns overhead by the Solarflare report we get a total
(simplified) processing time is 98ns non-crypto, 22ns for packet number,
and 22ns for AEAD totalling 142ns. So the packet number encryption overhead
would be 22/(98+22)*100% = 18%. The numbers ignore other QUIC bookkeeping,
but that can be done in other cores or outside the latency critical window.

This does not take into account that AEAD operation may operate less than
optimal because the packet number must be extracted first. On the other
hand, it is also not a disastrous overhead if no good alternative can be
found.

Earlier AES-NI I’ve seen from Intel doc suggests around 100cycles in HW for
a single AES-128 block which would be 33ns per packet number in the above
example.

On 10 February 2018 at 06.18.25, Mikkel Fahnøe Jørgensen ([e-mail])
wrote:

98ns for 68 byte messages