Re: Hardware acceleration and packet number encryption

[Eric Rescorla <[e-mail]>]

On Sat, Mar 24, 2018 at 9:35 PM, 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.
>

That's just a function of how the packet numbers are encoded. It's not
difficult to come up with a design that tolerates more reordering.

-Ekr


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