PGP: Specification vs. Implementation

In the previous blog postsI talked about the main features of PGP and about the keys that are used. In this blog I will explain the difference between the PGP specification vs. the implementations (like GPG) and why it’s important to keep this in mind.

Packets

PGP is in itself very open. While many implementations have some default order of signing, compressing and encrypting, PGP doesn't really care. And this can be quite burdensome.

PGP uses packets. The most important packets for now are:

1. Literal data packet (containing the plaintext message, encrypted or not).

2. Signature packet.

3. Compressed packet.

4. Encrypted data packet.

See here for more detailed information about these and other packets.

Note: the output can be ASCII armored to make it readable. If you do not armor it, the data will be a stream of bytes.

The specification of PGP does not specify a certain order of packets. It doesn't even specify that you need to provide any of them. You can choose to add some plain text data inside a literal data packet and as far as PGP is concerned it's completely valid. It's up to the implementation how to do this.

For this reason, always expect the unexpected unless you can create both the sending and receiving sides of the process. For example, GPG can basically process any message you can create with PGP.

Exception

One exception to this rule is the signature. Here the order is important:

1. A packet with information about the key.

2. A packet containing the data that is signed.

3. A packet with the actual signature.

Note: you might expect that these packets follow as separate packets. However, it’s possible to provide the final packet inside the second packet. As far as PGP goes this is valid, but this might give you errors if you’re not careful.

It's recommended to first sign the message and encrypt both the message and the signature. As far as compression goes, this can be done before or after the signing part, though it's common to first sign the message and then to compress it.

Don’t sign an encrypted message. This will tell everyone who has your public key you are the one who sent the message. While this might not be a problem for you, it will become a problem when your identity needs to remain secret. Encrypt both the message and the signature. This way only the receiver can tell who actually sent the message.

This is all the information that I wished I knew before starting with PGP. It would have helped me to know where to start and how to continue and search for more detailed information.