Module sequoia_openpgp::serialize::stream::padding

source ·
Expand description

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.

To pad a message using the streaming serialization interface, the Padder needs to be inserted into the writing stack between the Encryptor and Signer. This is illustrated in this example.

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

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

Structs§

Functions§

  • padme
    Padmé padding scheme.