Subject: Re: [quicwg/base-drafts] Packet number encryption (#1079)

From: MikkelFJ <[email-masked]>
Date: Mon, 26 Mar 2018 06:28:56 -0700

I mentioned a variation of this design on the mailing list but thought it better to make a note here as well.

1. The packet number is removed from the header and the AEAD protected content. This is safe because the packet number is the IV for AEAD.
2. The last 16 octets of the AEAD message (typically the full tag) is AES encrypted using a traffic key derived for this purpose.
3. The encrypted tag value is truncated to the length of the packet number and the packet number is encrypted by XOR'ed with this value.
4. The encrypted packet number is appended to the packet content after the AEAD tag.
5. The lenght of the packet number must be known. It can be fixed length, the length can be stored in the packet header, or it could be variable length with the last octet remainting some unencrypted bits.

The packet number is not useful without the tag and the tag is not useful without the packet number so it makes sense to store them together, typically in a single cache line. This also speaks for keeping the packet number length encoded last if not fixed length.

This approach avoids any modification to the AEAD packet content which can therefore be decoded without modification which is both good for hardware offload and is cache and synchronization friendly for multi-processor systems.

The approach does not consume more space than an unencrypted packet number.
Due to the linear dependency of packet number encryption there is an estimated latency of 24ns on current hardware because AES cannot take advantage of parallel operations. However, if there are multiple queued packets it might be possible to have the packet number decrypted efficiently by feeding the AES pipeline from multiple packets and then sending the result to the relevant receiving thread, all without additional bus traffic cause by buffer modifications.

-- 
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/pull/1079#issuecomment-376165638

---

From: MikkelFJ <[email-masked]>
Date: Mon, 26 Mar 2018 13:43:08 +0000 (UTC)

The above modification helps CPU cache but it does not helpware hardware that wants to decrypt while receiving data before the entire packet has been seen.

This can be achieved by moving the encrypted packet number before the AEAD content, and therefore before the packet header. The packet number would use the first encrypted bytes of the packet rather than the AEAD tag.

This is not as clean, but it would allow processing to start before the full packet has been seen.
Additionally, if a 1 octet checksum is added to the packet number, the packet number decryption could very quickly reject random packet content. This addtional benefit could pay for the addtional encryption overhead in DoS rejection.

-- 
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/pull/1079#issuecomment-376170252

---

From: Mike Bishop <[email-masked]>
Date: Tue, 27 Mar 2018 15:02:18 -0700

Note that #1077 has landed, so this can be retargeted/rebased onto master.

-- 
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/pull/1079#issuecomment-376690509