PGP: The Message Needed a Key, and the Key Needed a Name

Sending a private message requires an awkward preliminary agreement. The sender and recipient need some way to protect its contents, but arranging that protection can itself require a private conversation.

A shared secret works if both people already have it. Sending the secret through the same channel as the supposedly protected message rather undermines the exercise.

Public-key cryptography provides a different arrangement: a recipient can publish a key that others use to protect information for them, while keeping the corresponding private key. PGP put that idea into a working application for personal files and messages in 1991.

The useful part was the combination. Public-key operations handled a small piece of key material. A conventional cipher handled the larger message. Signatures addressed a different question again. The program brought those operations together without making their distinctions disappear.

A working distribution in June 1991

Philip Zimmermann’s announcement in the RISKS digest was dated June 7, 1991; the digest appeared June 11. It identified PGP 1.0 for MS-DOS as available for electronic distribution, with separate archives for the executable/documentation and C source.¹

The announcement presented privacy and authentication, combining RSA, conventional encryption, digests, compression and key management. Zimmermann described an educational working prototype and argued for public access to privacy technology. He also raised contemporary patent and export concerns. Those are part of his stated 1991 context, not current legal guidance.

The preserved beta 1.0 source was revised June 5, 1991. That is a source date; the announcement establishes availability by June 7.²

Its header names MD4 for signatures, LZHUF compression and Zimmermann’s BassOmatic conventional cipher. Later familiar algorithms should not quietly replace that original inventory. PGP 1.0 is a historical implementation, not the modern cryptographic system a reader should infer from the same initials.

Phil Zimmermann, later photograph; the source records August 10, 2001, while its event-description text contains an inconsistent 2011 label. Photo by CEphoto, Uwe Aranas, source, CC BY-SA 3.0. No alterations. This is not a 1991 photograph.

Two sorts of key do different jobs

Imagine Nora sending a message to Eli. These names and the message are invented.

Eli has a public key that Nora can obtain and a private key that he retains. Nora creates a fresh conventional key for the message. Call that temporary key K.

The message is encrypted using K. The key material is separately encrypted for Eli using his public key. The resulting package contains the encrypted message plus a protected way for Eli to obtain K.

Eli uses his private key to recover K, then uses K to recover the message. The conventional key is the immediate tool for the bulk data; the public-key operation gets that tool to the intended recipient.

This arrangement avoids repeatedly applying public-key arithmetic to every part of a long message. It also lets the public key be public. Possessing Eli’s public key is sufficient to prepare a message for him; it does not supply the corresponding private operation needed to recover the protected key.

The original encryptfile routine makes this distinction concrete. It obtains the recipient’s public key, generates BassOmatic key material, constructs a conventional-key packet and RSA-encrypts it, then compresses and conventionally encrypts the file.² Our diagram simplifies those packet details while preserving the division of work.

Original explanatory diagram, 2026. An invented message and temporary key illustrate hybrid encryption. This is not captured PGP output, its complete packet format, or an exact implementation trace.

Small arithmetic makes the public-key operation inspectable

A tiny RSA example can show the relationship between the keys. It cannot demonstrate practical security: the numbers below are deliberately small, and the arithmetic omits real encoding and padding.

Choose two primes, 61 and 53. Their product gives the modulus:

$$n=61\times53=3233.$$

For this teaching example, the associated totient is:

$$\phi(n)=(61-1)(53-1)=3120.$$

Choose a public exponent e of 17 and a private exponent d of 2753. Their useful relationship is:

$$17\times2753\equiv1\pmod{3120}.$$

The public pair is (3233, 17). The private exponent is part of the secret side. Take the invented integer 42 as our tiny stand-in for key material.

The public operation computes:

$$c=42^{17}\bmod3233=2557.$$

The corresponding private operation recovers it:

$$2557^{2753}\bmod3233=42.$$

The large exponents need not produce enormous stored integers before taking a remainder. Modular exponentiation can reduce intermediate results throughout the calculation. Our small checker uses Python’s modular pow operation to verify the values.

Item	Teaching value
Modulus n	3233
Totient	3120
Public exponent e	17
Private exponent d	2753
Original stand-in integer	42
Protected integer	2557
Recovered integer	42

The checker also verifies the round trip for every integer from zero through 3232. That is evidence about this deliberately chosen small arithmetic model. It is not a PGP test, a cryptographic audit or a recommendation to encrypt with textbook RSA.

In fact, the example reveals its own insecurity. Anyone can factor 3233 by testing a small number of candidates. Once the factors are available, the secret relationship is straightforward to reconstruct. The numbers are chosen for understanding, not protection.

PGP’s source adds random padding to public-key input.² Our unpadded equations are not its exact output. Here, repeating the operation on 42 always gives 2557: useful for checking arithmetic, unsuitable for illustrating that additional encoding.

A signature answers another question

Encrypting to Eli’s public key does not establish that Nora sent the message. Someone else could obtain the same public key and prepare another encrypted message.

Authentication requires additional evidence. A digital signature can tie a message to possession of the signing private key. The verifier uses the corresponding public key to check it.

The original signfile routine computes a digest of its input and creates a signature certificate using secret-key material. It supports attaching the message or keeping the signature separate.² A digest is a compact value computed from the message; the signing process works with that representation rather than treating secrecy and authorship as the same operation.

In our invented exchange, a successful signature check supports a narrower claim than “Nora wrote this.” It supports consistency between the message, the signature and the supplied verification key, subject to the scheme’s properties. Connecting that key to Nora is another step.

This distinction explains why signing and encryption can be combined without becoming interchangeable. Nora may want Eli to read the contents privately and also check the sender’s key. Alternatively, she may want anyone to read a signed public announcement. Those are different uses of the machinery.

A signature also does not make the message’s contents true. A signed mistaken appointment time remains mistaken. Cryptography can make the origin of a mistake more accountable; it cannot repair the calendar.

The key has to belong to the person you mean

Suppose Nora obtains a public key from an untrusted source labeled “Eli.” If that label is false, she can perform every encryption step correctly and protect the message for the wrong key holder.

Nothing in the modular arithmetic knows who Eli is. The name is information supplied around the key. Nora needs an independently supported connection between the key and her intended recipient.

Our example leaves the verification procedure unspecified because different circumstances provide different evidence. The general requirement remains: obtaining a public key and establishing its owner are separate tasks.

The same problem affects signatures. If the verifying key belongs to an impostor, a mathematically successful check can authenticate the impostor’s key perfectly well. The application must avoid silently promoting a convenient label into a trusted identity.

This is why key management deserves its place beside the headline cryptography. A tool has to help people store, find and reason about keys. It cannot simply replace every decision about identity with a successful calculation.

The observation is not a claim that PGP eliminated human trust or that its first release possessed every later trust-management feature. It explains the responsibility inherent in the public-key arrangement.

The first version and the later standard

PGP’s June 1991 release and OpenPGP’s later specification are different milestones. RFC 2440, the OpenPGP Message Format, appeared in November 1998.³ Its broader algorithm and packet descriptions should not be used to backfill the original application’s feature list.

Keeping that boundary also avoids judging a historical working prototype as if it were a current recommendation. The subject here is what PGP combined and made available, not an instruction to deploy its original algorithms today.

Its practical proposition was distinctive: personal privacy software could package public-key operations, bulk encryption and signatures in a tool distributed with inspectable source. People could examine machinery that otherwise risked remaining an abstract promise.

Consider Nora’s two possible failures. She might protect the right message for an impostor’s key, or send Eli a correctly protected message containing the wrong appointment. Fixing one problem doesn’t fix the other. The arithmetic is only one part of her task.

Those boundaries are more instructive than a general assurance that a message is “encrypted.” They tell us what each operation contributes and which questions remain outside it.

PGP made the private message more practical to prepare. The key still needed an identity, the sender still needed a reason to trust that identity, and the recipient still needed to understand what a successful check actually established. A useful tool can reduce the work without pretending that all the work is arithmetic.

Footnotes

1. Philip Zimmermann, Public Key Crypto Freeware Protects E-MAIL, message June 7, 1991, RISKS digest June 11. Complete announcement and postscript inspected. ↩

2. Philip Zimmermann, PGP 1.0 application source, preserved tagged source. Header, encryptfile, signfile and compression passages read; revision date distinguished from distribution date. ↩ ↩² ↩³ ↩⁴

3. Jon Callas and colleagues, RFC 2440: OpenPGP Message Format, November 1998. Later standard date and scope inspected; not used as a PGP 1.0 manual. ↩