Re: Hardware acceleration and packet number encryption

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

AERO: I did not read all of it, but it does indeed sound esoteric.
It can do two things of interest: reduce space used by packet numbers, and
presumably fix the encryption issue.

However, it has a W parameter which is the limit of reordering which is
default 64 and recommended at most 255 for security reasons. This is way
way too low (I would assume) if packet clusters take multiple transatlantic
paths.

If we accepted such a limit, I could very trivially come up with an
efficient solution to PN encryption. Since we cover at most 64 packets, we
only need a 5 bit packet number and reject false positives on AEAD tag. To
simplify, make it 8 bits. The algorithm is to AES encrypt a counter similar
to a typical AES based PRNG. Then, for each packet take one byte from the
stream and use it as packet number. The receiver creates the same stream
and maps the received byte to an index it has. It might occasionally have
to try multiple packet numbers since the mapping is not unique. Longer
packet numbers reduce this conflict ratio. To help with this detection some
short trial decryption might be included. The PN size can be extended as
needed.

The cost of doing this is much lower than direct encryption for as proposes
in PR because 1) a single encryption covers multiple packets, 2) the
encryption can be parallelised resulting in a 4-5 fold performance
increase. Combined this results in sub-nanosecond overhead for AES-NI.

However, you have to deal with uncertainties which is why this isn’t a very
good idea unless you have some very good knowledge of the traffic pattern.
It also complicates HW offloading, but I don’t see why it couldn’t be done
efficiently.


Mikkel


On 24 March 2018 at 17.26.47, Eric Rescorla ([e-mail]) wrote:

3. A more exotic solution like AERO (
https://tools.ietf.org/html/draft-mcgrew-aero-00#ref-MF07)..