Re: [openpgp] Padding packets

[Ángel <[e-mail]>]

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.


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.


> A better mechanism to add padding is by handling
> this at the MIME layer.

How do you expect to handle this at the MIME layer? Or even if it's not
use in the context of an email message?


See for instance the scenario posed last year in
https://lists.gnupg.org/pipermail/gnupg-users/2021-January/064771.html
(Message-ID: <[e-mail])

That's in the context of WKD, where an external observer could
determine the openpgp keys fetched *inside an https transport*.
How would "MIME padding" fix that?


Regards