Re: [openpgp] Padding packets

["brian m. carlson" <[e-mail]>]

On 2022-06-15 at 23:43:00, Ángel wrote:
> On 2022-06-15 at 13:29 +0200, Werner Koch wrote:
> > Hi!
> > 
> > The idea of a padding packet is in general a good idea and has been
> > discussed many times:
> > 
> >    5.14.  Padding Packet (Tag 21)
> > 
> >    The Padding packet contains random data, and can be used to defend
> >    against traffic analysis (see Section 14.10) on version 2 SEIPD
> >    [...]
> >    Its contents SHOULD be random octets to make the length obfuscation
> >    it provides more robust even when compressed.
> > 
> > The problem with random padding packets is that this opens a high
> > capacity channel with all its problems.
> 
> I agree. I think this was noted in the past, as well.

I agree that this seems undesirable here.

> However, we don't need this to be random, it can be deterministic yet
> incompressible.
> Take a symmetric-key algorithm, use it in counter mode with the hash of
> the previous packet as key (or IV). That will produce an output which
> should not be compressible. Yet, it produces a deterministic padding
> that can be verified by the receiving application.

If we didn't have to deal with compression, I'd simply say we could fix
it at all zeros.  Since we do, maybe we want to just make it a fixed
value, say, the output of SHA-256 on an increasing 8-byte big-endian
counter starting at 0.  That provides practically infinite padding, is
always a fixed value (which can be verified), and, because SHA-256 is
believed to be indistinguishable from random, practically
uncompressible.

Since this packet would already have been verified by the AEAD, the
implementation doesn't have to provide complex constant-time padding
verification, which is a hassle and a source of bugs.
-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA