Re: [openpgp] Padding packets

[Daniel Huigens <[e-mail]>]

On Wednesday, June 22nd, 2022 at 01:02, Daniel Kahn Gillmor wrote:

> You're right that the metadata fields in OpenPGP packets are themselves
> fairly low-entropy, so the protection a padding packet can provide
> against compression isn't going to be bulletproof.

It's not just that, the content of the message itself is also often
low-entropy, so if we want to hide the length, it shouldn't be
compressed (or should be padded *after* compression).

> IIRC, the padding packet was initially proposed as containing all-zeros,
> as a way to avoid adding yet another side channel; the DT changed it to
> high-entropy data specifically because of concerns about compression.

Yeah, I know. Back then I objected to the language that said that this
was "to make the padding robust against compression", which I didn't
think was true, so it was changed to "more robust". That is of course
better but I would personally still prefer not to imply any robustness
of the (length obfuscation offered by) padding after compression.

> If we recommend that the packet contain all-zeros as proof of
> no-covert-channel, i still don't think it's advisable to require
> implementations to reject the entire packet sequence if any non-zero
> data is found in a padding packet. At most i'd say that some
> implementations may want to warn the user that there may be hidden
> data (but see [] below).

Sure, I'd be fine with that.

> So the padding packet doesn't open a new covert channel, regardless of
> how it is specified.

I agree.

Though one thing I like about this change (or specifying all zeros) is
not having to generate large amounts of random data. Section 14.9
(Random Number Generation and Seeding) gives some guidance about that,
but not having to do so in the first place simplifies things, imo.

But perhaps we can just leave it open; and allow the implementation to
choose between all zeros and random data, for example.

Best,
Daniel