Subject: [quicwg/base-drafts] Consider simplifying Packet Number Encryption (#1575)

From: David Schinazi <[email-masked]>
Date: Tue, 17 Jul 2018 15:27:36 +0000 (UTC)

Currently PNE encrypts the variable-length packet number. There are at least two ways to implement decryption:

1. decrypt the first byte in-place, compute the PN length, decrypt the remaining bytes in-place
2. decrypt the max PN length (4 bytes) into a separate buffer, compute the PN length, copy that amount of bytes back

This has the downside of worse performance, or can cause timing attacks.

It would be simpler to always encrypt the max length - that way we can always decrypt 4 bytes in place.

Apologies if this has been discussed before, I wasn't able to find it.

-- 
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/1575

---

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

If you send very short messages such as PING you risk overlapping with the AEAD tag and then it starts to get interesting figuring out how to decrypt the packet number.

-- 
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/1575#issuecomment-405643429

---

From: David Schinazi <[email-masked]>
Date: Tue, 17 Jul 2018 11:02:39 -0700

I'm not sure I understand, can you elaborate? You just decrypt four bytes - having that flow into the tag is not a problem

-- 
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/1575#issuecomment-405672905

---

From: Martin Thomson <[email-masked]>
Date: Tue, 17 Jul 2018 11:22:47 -0700

I think that this is purely editorial: the draft doesn't actually describe a process for decryption, just points at considerations.  Are you suggesting that we recommend a specific method?  I think that any of these options are fine.

-- 
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/1575#issuecomment-405680109

---

From: David Schinazi <[email-masked]>
Date: Tue, 17 Jul 2018 11:25:04 -0700

Sorry, I meant that we could change the amount we encrypt - always encrypt four bytes instead of just the PN.

But thinking about this some more I understand @mikkelfj 's comment. If we encrypt the sample we'll have a hard time decrypting... Would it be reasonable to reduce the size of the sample for very short packets?

-- 
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/1575#issuecomment-405680790

---

From: Martin Thomson <[email-masked]>
Date: Tue, 17 Jul 2018 11:30:25 -0700

@DavidSchinazi , I see.  We shouldn't really reduce the sample size.  That is, if you value the strength of the encryption.  Either way, it shouldn't be necessary.

-- 
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/1575#issuecomment-405682507

---

From: David Schinazi <[email-masked]>
Date: Tue, 17 Jul 2018 11:41:35 -0700

I agree that this isn't necessary - I'm just wondering if this proposal could make implementations simpler and safer.

Proposal: always encrypt four bytes [pn_offset, pn_offset + 3] and always have the sample start at pn_offset + 4. If the sample were to overflow the payload + tag (which only happens if you use 128-bit AES and have pn_len + payload_len < 4), you just pad the sample with zeroes. In the worst case scenario the sample contains two bytes of zero but you still have a 128bit secret key. Is that unacceptable?

-- 
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/1575#issuecomment-405685938

---

From: Martin Thomson <[email-masked]>
Date: Tue, 17 Jul 2018 11:54:59 -0700

I wouldn't say unacceptable, but it does lower the birthday bound.

-- 
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/1575#issuecomment-405690048