Padding for OpenPGP messages.
To reduce the amount of information leaked via the message length, encrypted OpenPGP messages (see Section 11.3 of RFC 4880) should be padded.
There are a number of ways to pad messages within the boundaries of the OpenPGP protocol, keeping an eye on backwards-compatibility with common implementations:
Add a decoy notation to a signature packet (up to about 60k)
Add a signature with a private algorithm and store the decoy traffic in the MPIs (up to 4 GB)
Use a compression container and store the decoy traffic in a chunk that decompresses to the empty string (unlimited)
Use a bunch of marker packets, which are ignored (each packet: 3 bytes for the body, 5 bytes for the header)
Apparently, GnuPG understands a comment packet (tag: 61), which is not standardized (up to 64k)
We believe that padding the compressed data stream is the best option, because as far as OpenPGP is concerned, it is completely transparent for the recipient (for example, no weird packets are inserted).
Unfortunately, testing discovered problems when the resulting messages are consumed by (at the time of this writing) OpenPGP.js, RNP, and GnuPG. If compatibility with these implementations is a concern, using this padding method is not advisable.
To be effective, the padding layer must be placed inside the
encryption container. To increase compatibility, the padding
layer must not be signed. That is to say, the message structure
(encryption (padding ops literal signature)), the
exact structure GnuPG emits by default.
Pads a packet stream.
Padmé padding scheme.