Re: Hardware acceleration and packet number encryption

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

Another approach that could be explored is carry-less multiplication in the
GF(2^n) domain. This could reduce the size of required bits to make a
mapping which would be non-trivial to break. GCM uses something along these
lines for hashing, but in a 128 bit domain. My math foo is not strong
enough to say if this is a good idea. If it could be done with a CLMUL
instruction the overhead would be low and where it isn’t supported, GCM
suffers too.

One could also be less ambitious and use a seeded hash and deal with the
odd conflict, for example:
Faster 64-bit universal hashing using carry-less multiplications
https://arxiv.org/pdf/1503.03465.pdf

But both of these potential approaches probably suffer when the packet
number length drops down to 8 or 16 bits. Which is why we are back the the
encryption of an AES block that overlaps with other content leading to so
called double buffering.

On 24 March 2018 at 22.35.26, Mikkel Fahnøe Jørgensen ([e-mail])
wrote:

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)..