Subject: [quicwg/base-drafts] Keep PN out of AEAD (#1578)

From: MikkelFJ <[email-masked]>
Date: Tue, 17 Jul 2018 09:50:21 -0700

If the packet number is not included in AEAD then there is no reason to modify the receive buffer to verify the packet. Since the packet number is used as IV it is verified regardless.

Most encryption functions have a function like
decrypt (key, IV, auth-data, auth-data-len, cipher-text, cipher-text-len, tag)
verify (key, IV, auth-data, auth-data-len, cipher-text, cipher-text-len, tag)

```
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+
|0|K|1|1|0|R R R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                Destination Connection ID (0..144)           ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<end of authenticated data>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Packet Number (8/16/32)                ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<start of encrypted data>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Protected Payload (*)                   ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
```

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1578

---

From: MikkelFJ <[email-masked]>
Date: Tue, 17 Jul 2018 09:54:56 -0700

So not sure why github posted that before I was done, but

it means that the packet number can stay as it is but not affect the tag. This means the decryption and verification can be done by copying just the encrypted PN to a small side buffer to derive the IV and then verify or decrypt without having to modify the incoming payload.

This can simplify hardware and multi-processor buffer sharing.

It also simplifies decrypting the PN because it can be decoded as if it were full length and never bother potential for overwriting data that is not part of the PN - since it happens in a separate buffer as discussed in https://github.com/quicwg/base-drafts/issues/1575

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1578#issuecomment-405652289

---

From: MikkelFJ <[email-masked]>
Date: Sat, 28 Jul 2018 23:54:22 -0700

Based on discussion on the mailing list there are two issues to be aware of:

1. There is no clear text packet number length and this makes parallel operations less effective
2. A verified tag does not lead to a unique packet

The first issue can be resolved by keeping the length in clear text. The second issue can be resolved by either including the packet number length field in AEAD or by requiring the packet number length to be the shortet possible.

It is not clear if making the PN length visible would cause problems, but even encrypted the length can be learned after transmitting a few modified packets and observing if the packet gets accepted.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1578#issuecomment-408656387

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 29 Jul 2018 16:44:26 -0700

Note that in #1322 we have been discussing how to protect the KEY_PHASE bit.

Decryption of AEAD will still depend on the result of PN decryption even if we make changes being dicsussed in this PR, if we adopt a solution like encrypting the KEY_PHASE bit using the PNE key or determining the key based on the value of the PN.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1578#issuecomment-408714511