Re: Hardware acceleration and packet number encryption

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

The tag used as IV in ECB mode for PN enceryption will use a full block
size which is 16 octets. The proposal was encrypt the tag and XOR the
result over that packet number and what follows.

If this is what is meant by “tag as IV” it is problematic for what I assume
is meant by double buffering, i.e. the need to modify the packet buffer
decryption. This is because the packet number and what follows must be
un-XORed before verification can take place.

You could keep the packet number out of AEAD, but you cannot afford to
waste the additional 16-4=12 octets or more that an AES block encryption
uses, so you a stuck with modifying the buffer post AEAD.

Finding alternative nonces won’t fix this problem. If you encrypted the
header completely separately from the body, you could do something, but
then you waste space on extra header tags.


My suggestion with GF(2^n) will not work because: even if it works in
principle (finding an ideal in GF(2^32) and multiplying a seed with packet
number modulo ideal), it is easy to brute force 2^32. Alternatively you can
do chained hashing similar to how GCM’s GHASH works but then is not a
unique mapping, but that is not better the CTR mode encryption PRNG style,
and likely slower. Why would you do this at all, if it worked? Because at
allows you to stick to encrypting only the packet number that can stay
outside AEAD and thus avoid buffer modification. But I don’t see how it can
work.

Mikkel

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



On Sat, Mar 24, 2018 at 9:41 PM, Subodh Iyengar <[e-mail]> wrote:

> When we were first discussing pne, we proposed that the tag be used as the
> IV for the ctr operation. The pr samples encrypted data in the packet. Did
> we change that for a reason?
>

I believe that's my alternative #1 and PR#1079.


Would that help alleviate the buffering of the stream data? Because tag is
> always the last thing in the packet.
>

I will let Manasi answer this.


-Ekr


>
> Subodh
>
>
> On Mar 25, 2018, at 2:56 AM, Eric Rescorla <[e-mail]> wrote:
>
>
>
> On Sun, Mar 25, 2018 at 2:09 AM, Deval, Manasi <[e-mail]>
> wrote:
>
>> From talking to several of the folks last week, I understand that
>> unlinkability is the goal of this protocol and there may be some
>> flexibility in how that can be achieved.
>>
>>
>>
>> Christian’s e-mail has a detailed list of options.  Here is the list of
>> favored options as I understand them.
>>
>>
>>
>> 1.      Packet number encrypted as current suggestion - The current
>> proposal for PR 1079, uses a two stage serialized approach such that the
>> stream header(s) and payload(s) need to be encrypted and the outcome of
>> encryption forms the nonce of the packet number encryption.
>>
>>
>>
>> 2.      Packet number encrypted alternative 1 - One of the ideas
>> suggested was to encrypt the stream header(s) and payload(s) with the
>> packet number as nonce, but have an additional nonce in the clear to
>> encrypt the packet number. A scheme like this can allow for these two
>> encryption operations to occur in parallel. This still has the issue of
>> serialization in decrypt.
>>
>>
>>
>> 3.      Packet number encrypted alternative 2 – Another option is to
>> generate 2 IVs – one for PN and the other for stream header(s) and
>> payload(s). The nonce can be a random value in the clear. This allows us to
>> encrypt and decrypt the two fields in parallel. The packet number is
>> encrypted so it also solves the ossification problem. Another variation of
>> this is to generate a single IV but use one part of it to encrypt the PN.
>>
> Neither of these alternatives seems ideal. Once you are carrying an
> explicit per-packet nonce, you might as well concatenate the payload and
> the PN and encrypt them together. The will require the least amount of
> nonce material.
>
> -Ekr
>
> 4.      PN in the clear – this is a complex scheme and in the discussion
>> with Ian, Jana and Praveen, they seemed to think this may be ok. If folks
>> think this is implementable, then we may need to find an alternate solution
>> for ossification.
>>
>>
>>
>> Thanks,
>>
>> Manasi
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *From:* Eric Rescorla [mailto:[e-mail]]
>> *Sent:* Saturday, March 24, 2018 3:18 PM
>> *To:* Mikkel Fahnøe Jørgensen <[e-mail]>
>> *Cc:* Kazuho Oku <[e-mail]>; Deval, Manasi <
>> [e-mail]>; Christian Huitema <[e-mail]>; IETF
>> QUIC WG <[e-mail]>
>> *Subject:* Re: Hardware acceleration and packet number encryption
>>
>>
>>
>>
>>
>>
>>
>> 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/d
>> raft-mcgrew-aero-00#ref-MF07
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dmcgrew-2Daero-2D00-23ref-2DMF07&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=Kqui4PrKKRuP58njW3vlK_ZPgcQX0TQ9iXVtGY1Kp30&s=GthDylmhvmHUnMvnjBT05qJT9VrOTknvVoMbdC7ObLo&e=>
>> )..
>>
>>
>>
>>
>>
>
>