[][src]Module sequoia_openpgp::serialize::padding

Padding for OpenPGP messages.

To reduce the amount of information leaked via the message length, encrypted OpenPGP messages should be padded.

Padding in OpenPGP

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).

Cursory testing (RNP, DKGPG, PGPy, OpenKeychain, GnuPG classic and modern) revealed no problems.

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 should be (encryption (padding ops literal signature)), the exact structure GnuPG emits by default.

Structs

Padder

Pads a packet stream.

Functions

padme

Padmé padding scheme.