Subject: RE: Change to padding in encryption -- enabling random access

From: "Manger, James" <[email-masked]>
Date: Mon, 30 Jan 2017 05:44:56 +0000

Random access to content via a range request is almost supported by aes128gcm, but as the draft says it "could be confounded by the presence of padding". You can decrypt, say, the 100th 1KB record, but that gives you no clue how many of the earlier 99,693 bytes are content vs padding — unless you are told.

How about a flag in the padding delimiter byte that, if set, means there is no padding in earlier records?

An encryptor that wants to enable random access can easily flag this in an authentic manner.
A decryptor that doesn't care can easily ignore the flag.

Typo in PR #283:
✗ "all other octets have a padding delimiter with the value 1"
✓ "all other records have a padding delimiter with the value 1"

--
James Manger

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]] 
Sent: Monday, 30 January 2017 3:59 PM
To: HTTP Working Group <[email-masked]>
Subject: Change to padding in encryption

Based on the discussion thus far, I've put together a PR that changes
how padding works.

https://github.com/httpwg/http-extensions/pull/283

---

From: Martin Thomson <[email-masked]>
Date: Mon, 30 Jan 2017 16:50:48 +1100

> How about a flag in the padding delimiter byte that, if set, means there is no padding in earlier records?

It was always my thought that this sort of signal could be carried out
of band even more easily.  Indicating to a random access reader that
padding is always at the end achieves the goal without increasing
per-record complexity anywhere.

> ✓ "all other records have a padding delimiter with the value 1"

Thanks.

---

From: "Manger, James" <[email-masked]>
Date: Mon, 30 Jan 2017 06:04:10 +0000

> per-record complexity anywhere.

But an out-of-band signal doesn't sound easy. Maybe the distribution of the key (IKM) could say "no padding will ever be used with this key". But that feels fragile, and is per-key not per-message. Other signals from the web server don't help as the point of an encrypted content-encoding was not to have to trust the web server.

Padding is in-band even when the encryptor doesn't want to use any, so an in-band signal that there is no earlier padding doesn't feel like complexity that is out-of-place.

--
James Manger

---

From: Martin Thomson <[email-masked]>
Date: Mon, 30 Jan 2017 17:27:12 +1100

> Padding is in-band even when the encryptor doesn't want to use any, so an in-band signal that there is no earlier padding doesn't feel like complexity that is out-of-place.

That would be true if you consider the random access use case to be
common enough to justify any complexity at all.