There seems to be an ongoing misunderstanding of how PGP actually does authentication. That ends up being important in various discussions. Let's dig into perhaps the more interesting question of why PGP does the things it does and pick up the how along the way.

Authentication in a PGP context is a mechanism that makes it possible for the recipient of a file/message to verify that the file/message was certified by a particular entity/person. It also insures that the file/message was not tampered with after that certification. Since the tampered file/message would be different, the certification would not apply to it. The most common convention is that the certification is a declaration that the certifier created a particular file/message. More generally, such a certification means that the certifier is taking responsibility for the file/message in some way.

Cryptographic signatures will be important here so we should briefly define the term. The generation of a cryptographic signature requires knowledge of a secret value normally only known by single entity/person. There is a public value that corresponds to the secret value. Anyone can take that public value, the signed data and the cryptographic signature and verify that the signer had access to the secret value when they created the cryptographic signature. Cryptographic signatures often form the root of authentication schemes.

TLS is a popular system used to provide privacy and authentication for network oriented media. Say the world wide web. This very website is using TLS.

Most people seem to implicitly assume that cryptography works the way things like TLS work. Then they think about PGP and the concepts kind of mix together, particularly if the TLS concepts are not entirely clear. So it would be good to get a clear view of how and why TLS does authentication before we talk about how and why PGP does authentication.

OK. Let's set the wayback machine to 1995. There is something called the Internet. It is awesome for distributing human knowledge but wouldn't it be great for stuff like selling things and banking? For that we need privacy and authentication. Privacy is just encryption. That's easy. Authentication turns out to be harder.

You send things on the Internet by breaking your data into a bunch of individual packets and sending them off. Each packet is treated separately and has an individual adventure. They can take different paths and might not even get to the destination in the correct order. So you would have to apply authentication to each individual packet. This sort of network is referred to as “connection-less”.

We could just apply a cryptographic signature to each packet. That would work but is a poor idea for more than one reason…

The signatures are large. For example, a RSA signature could be 256 bytes long (2048 bit key). Even if we anticipate the future, a signature based on an elliptic curve scheme would be at least 64 bytes long. The packets are small. They are only 1500 bytes or less. The signatures would represent significant overhead. The 1500 byte limit is a hard limit. Adding a signature would significantly reduce the maximum amount of data that could be sent in the packet. So applying authentication would cause an awkward problem for the networking system.

The signatures are slow. Signing and then verifying the signature on each and every (small) packet would create a significant processing requirement.

So we wonder if things might be less difficult on a connection oriented network. Well, the world wide web (which is what we are primarily targeting) runs on top of the Transmission Control Protocol (TCP) which adds a connection oriented protocol on top of the connection-less Internet. With TCP we have a definite start of a connection, a middle part and an end. So here is what we do:

1. The client (say a web browser) makes a TLS request of the server.
2. The server (say a web server) sends its identity information to the client.
3. The client verifies that the identity information corresponds to the desired server using cryptographic signatures. Authentication is established at this point.
4. The client then uses the server's identity information to send some secret value to the server (“public key encryption”), safe in the knowledge it is sending that value to the right server due to the authentication.
5. Now the client and server have a shared secret value. They can then derive all the other required secrets for both encryption and authentication.

This is called a “handshake” because it involves a number of data transfers alternately back and forth between the server and client.

For each packet transferred as part of the TCP connection we do the following:

1. The sender encrypts the packet using the shared encryption secret value. The sender also generates an integrity check value using the shared secret information and appends it.
2. The receiver decrypts the packet using the shared encryption secret value. The receiver uses the shared secret information and the integrity check value to verify that:
   1. The packet has not been modified.
   2. The packet was not created by a third party.

Since the shared secret information was authenticated during the TLS handshake phase, a valid integrity check gives us authentication more or less for free. The integrity check is much shorter (say 16 bytes) and faster than a cryptographic signature. By breaking the authentication into a separate phase we have solved both of our efficiency problems.

All the shared secret information can now be safely forgotten.

Since the integrity check used in TLS is always used in a way that provides authentication, the encryption modes that provide an integrity check are conventionally called “authenticated encryption”. I have to make the distinction here to avoid confusion later on in the discussion.

This sort of connection oriented approach is often used for the authentication of end to end encrypted instant messaging. There is often some concept of a session in instant messaging that can be treated like a connection. So we are not just comparing against encrypted pipe applications like TLS here.

For the files/messages that PGP is applicable to, there is only one file/message. That file/message is not broken into packets. So here is what we do for PGP authentication:

1. The sender generates a cryptographic signature from the file/message and sends it along with the file/message.
2. The receiver uses the signature to check that:
   1. The file/message has not been modified.
   2. The file/message was not created by a third party.

That's it. That's the whole thing. Optionally the sender can encrypt the file/message and signature but that has nothing to do with the authentication.

At this point it should be fairly obvious why PGP does authentication this way. It is probably the simplest and most straightforward way to do it. As a minimalist I am generally in favour of this sort of thing. Simplicity supports security.

Note that the TLS approach links the authentication with the encryption. You can't have one without the other. In the PGP case the authentication is entirely separate from encryption. OpenPGP formatted signatures are routinely used without encryption for things like verifying the provenance of distributed software. PGP signing without encryption is probably more common than PGP encryption. The PGP approach to authentication makes this possible.

Having independent authentication and encryption means that the concepts can map directly to paper mail. The signature maps to the name written at the end of the message. The encryption maps to the use of an envelope. So the user can select none, either or both just as with paper mail and will understand the implications of their choice. Since PGP originally targeted email as a transport method this would have been important as email is closely based on paper mail concepts. Exploiting preexisting cultural concepts can be a very powerful method of improving usability.

PGP authentication does not require a handshake. That is essential for things like encrypted email. You would not want to have to swap several email messages before you could know who was sending them.

As opposed to things like TLS, PGP does not require any sort of ongoing integrity check. Which brings us to the next topic…

The very existence of this mode seems to confuse people¹⁾. It is a mode with, you guessed it, no integrity check. It is pure encryption. We should have a pretty good idea at this point about why it exists. Since PGP authentication is done directly on the data there is simply no need for anything else. An encryption mode that provided an integrity check feature would be redundant and would cause inefficiency.

So there is a PGP encryption mode with an integrity check²⁾. For those of us who know how PGP authentication works the existence of this mode is confusing.

People were happily and securely using the OCFB encryption mode with PGP authentication for many years. The OCFB-MDC mode came along later.

A valid OCFB-MDC integrity check insures:

1. The file/message has not been modified.

Since there is nothing like the “TLS handshake” to link authentication to the integrity check we don't get any assurance that the file/message has not been created by a third party. Oh, and just for the record, none of the proposed replacements for OCFB-MDC (at least four at the time this was written) do anything different. They only provide an integrity check, not any sort of authentication.

So why does the OCFB-MDC encryption mode exist at all? It's specifically for the case of anonymous (unsigned, unauthenticated) files/messages. We won't know where the file/message came from, but at least we know it wasn't tampered with. It's better than nothing.

In practice almost all implementations will emit OCFB-MDC encrypted messages even if the file/message is signed. That makes it so that schemes that depend on the integrity check will always have it available without consideration of the authentication status of the message. The resulting inefficiency is apparently considered an acceptable cost. Those implementations that do not require the integrity check can simply just ignore it.

When working with PGP, it is important to clearly understand the difference between authentication and the integrity check. The integrity check is limited and often full authentication is required or more desirable.