PGP and OpenPGP: From 1991 Software to a Shared Message Format

Pretty Good Privacy (PGP) made public-key cryptography usable for ordinary files and electronic messages on personal computers. Its importance was not that it invented encryption or email security, but that it packaged several cryptographic operations into software people could run and exchange. PGP combined a public-key system for signatures and key distribution with conventional symmetric encryption for bulk data, then added compression and an ASCII-safe representation suited to the mail systems of the time.

PGP’s creator, Philip Zimmermann, first released version 1.0 in 1991. That date is recorded in RFC 1991, a 1996 informational document co-authored by Zimmermann that describes the formats used by PGP 2.x. The distinction matters: RFC 1991 did not define the first release in 1991; it documented a later family of packet formats and explicitly identifies the earlier 1.0 release as the precursor.

Hybrid encryption solves a practical performance problem

Public-key operations are useful for establishing identity and protecting small pieces of data, but bulk encryption is generally more efficient with a symmetric key. PGP therefore generated a fresh random session key for a message, encrypted the message with a conventional cipher, and encrypted the session key with each recipient’s public key. A recipient used their private key to recover the session key, then decrypted the message.

The pattern was called hybrid encryption because it combined two cryptographic systems with different roles. The sender could encrypt one message for multiple recipients by including a protected session key for each recipient while encrypting the body once. That made it feasible to encrypt sizeable files without asking a public-key algorithm to process every byte.

Signatures used a different path. PGP computed a message digest and used the sender’s private signing key to produce a signature. The recipient could use the corresponding public key to verify that the content matched the signed digest and that the signature was generated by someone with access to the private key. Verification does not prove that the key belongs to a particular legal person; the user still needs a trustworthy way to bind a public key to an identity.

RFC 1991 describes additional services that helped PGP work with contemporary mail systems. It used compression, ASCII armor that converted binary packets into printable characters, and CRC checks to detect transmission errors. ASCII armor was a transport accommodation, not encryption or authentication. A visible block beginning with BEGIN PGP MESSAGE is a representation of encoded packet data; it does not by itself tell a recipient whether the message is confidential or signed.

The key question is identity, not only mathematics

PGP’s original trust model became known for its “web of trust” approach. Instead of relying solely on one global certificate authority, users could sign one another’s public keys to express confidence that a key was associated with a person. That model offered flexibility and independence, but it required users to decide whose signatures to trust and how much confidence to propagate. A valid cryptographic signature can still be attached to a key whose owner is unknown or misidentified.

Key servers helped distribute public keys and signatures, but a key server could not magically validate the identity information users uploaded. A search result for a name or email address is not proof that the returned key belongs to the intended recipient. Fingerprint comparison through an independent trusted channel, organizational key directories, hardware-backed key enrollment, and documented verification practices address different parts of the identity problem.

This is why PGP signatures and encryption solve different questions. Encryption aims to prevent parties without the required key from reading content. A signature aims to allow verification that content matches a signing key. Neither property guarantees that the message is timely, that the sender’s key has not been compromised, or that a signed statement is factually true. Nor does a signature automatically provide legal non-repudiation; that depends on key control, policy, and evidence beyond the algorithm.

From software package to interoperable OpenPGP format

Early PGP versions were implementations created under Zimmermann’s design guidance. As use spread, interoperability required a stable description of packet formats, public keys, signatures, and encrypted messages. RFC 1991 documented PGP 2.x formats in 1996. The Internet Engineering Task Force later formalized OpenPGP as an interoperable message format in RFC 2440, followed by RFC 4880 in 2007.

OpenPGP is a format and protocol family, not one specific application or vendor. Multiple implementations can read and write OpenPGP packets while providing different user interfaces, storage systems, key management, and policy. That separation makes exchange possible, but feature support still varies. Users should confirm that sender and recipient agree on algorithms, packet features, key formats, and trust procedures.

RFC 9580, published in July 2024, obsoleted RFC 4880 and updated the OpenPGP format. It defines packet formats for encryption, decryption, signatures, compression, and key management, and includes security requirements for handling malformed or integrity-protected data. The current standard emphasizes that an implementation must not parse or release plaintext from a message whose integrity checks fail. Historical mail clients and archives may contain old PGP data, so modern software must handle legacy formats carefully rather than assuming every old ciphertext has current integrity protections.

The OpenPGP packet model makes the format extensible. Messages consist of packets with tags and lengths that identify their contents. A signed-and-encrypted message may contain nested packet structures. That flexibility supports different operations and metadata, but parsers must enforce packet lengths and reject malformed input. RFC 9580 describes defensive parser behavior because a format that handles attacker-controlled messages is part of the security boundary.

Why PGP mattered in the 1990s

The 1990s saw growing public access to networked computers and intense debate about who could use strong cryptography. PGP gave individuals a way to encrypt files and messages without waiting for a proprietary mail system to add a vendor-specific feature. Its distribution helped make cryptographic software a public and practical subject, not only a topic for government, military, or academic laboratories.

That significance should not be reduced to one oversimplified legal narrative. The history of PGP includes debates about export controls and software publication, but a production article should rely on court records, contemporaneous statements, or archival material for specific claims about investigations and legal outcomes. The core technical story is already substantial: an implementable package turned public-key signatures and session-key encryption into a format people could exchange through ordinary channels.

OpenPGP is not a complete secure-email system

OpenPGP protects selected message content; it does not automatically hide metadata such as sender, recipient, timing, message size, or routing headers. Email transport systems still process envelope information. A user’s endpoint can expose plaintext before encryption or after decryption. A compromised private key or device can defeat confidentiality even when the packet format is correct.

Encryption can also create integrity and parser risks if software mishandles legacy ciphertext. Security research has demonstrated that implementations must verify integrity before exposing plaintext to higher-level processing. RFC 9580 directs implementations to stop and report an error when integrity is suspect rather than parsing partially decrypted data. A user should keep software current and heed verification failures instead of treating a displayed partial message as trustworthy.

Key management is often harder than invoking an encryption command. Private keys need secure storage and backup; a lost key can make old encrypted files unrecoverable. Revocation certificates should be prepared and stored separately. Key expiration, rotation, and revocation need to be communicated to correspondents. A public key downloaded from an unverified source can encrypt a message to an impostor. Organizational users may prefer managed certificates or directory systems that provide auditable enrollment and revocation, while independent users may accept a more manual trust process.

Reading PGP’s legacy accurately

PGP’s history has three distinct layers: the 1991 software release, the later PGP 2.x message formats documented in RFC 1991, and the OpenPGP standards track that produced RFC 2440, RFC 4880, and the current RFC 9580. Treating those as one event obscures how a useful program became an interoperable format. The original hybrid design made cryptography practical for ordinary data; later standardization allowed different tools to exchange messages; ongoing revisions addressed security and compatibility issues.

PGP did not make trust automatic or remove the need to maintain keys. It gave individuals and organizations a portable way to encrypt and sign data using public keys, and it helped establish a shared format that outlasted any one implementation. Its most durable lesson is architectural: cryptographic primitives, identity binding, user workflow, and file formats must work together. A packet can be mathematically well-formed and still be addressed to the wrong person, created by a compromised device, or interpreted unsafely by outdated software.

Related:

Sources: