up:: In the Protocols MOC

S-MIME and OpenPGP

S/MIME and OpenPGP are the two long-standing standards for end-to-end encrypted and digitally signed email, and they do the same two jobs, confidentiality and authenticity, but disagree on how a sender decides a recipient’s public key is genuine. S/MIME leans on X.509 certificates issued and vouched for by a Certificate Authority, the same centralized PKI that underwrites the web, so it dominates corporate and government mail. OpenPGP (the open standard behind the tool most people still call PGP) uses a decentralized web of trust, where users sign each other’s keys directly and no central authority is required, which is why it took hold with journalists, activists, and developers.

Both encrypt a message the same way underneath: a random symmetric key locks the body, and a classical public-key algorithm (RSA or ECDH) wraps that symmetric key to each recipient. That wrapping step is exactly what a quantum computer running Shor’s algorithm breaks, and because email lives in archives for years, encrypted mail is one of the clearest harvest-now-decrypt-later surfaces there is.

This is a protocol note in the applied-PQC hub

It covers where the cryptography lives in encrypted email, why the confidential half is harvestable and the signing half is not, and how the IETF has already standardized post-quantum profiles for both formats.

The short version:

1. S/MIME and OpenPGP are two competing standards for the same goal, encrypting and signing email end to end, defined by RFC 8551 (S/MIME 4.0) and RFC 9580 (OpenPGP).
2. Their real difference is the trust model. S/MIME trusts an X.509 certificate because a CA signed it; OpenPGP trusts a key because people you already trust signed it (the web of trust).
3. Encrypted email is a harvest-now-decrypt-later problem. The message body is protected by AES, but the key that unlocks it is wrapped with classical RSA or ECDH, and mail sits in archives long enough for a future quantum computer to catch up.
4. Signed email is the opposite exposure. Forging a signature is a Non-HNDL threat that needs a live quantum computer at the moment of use, so there’s nothing to harvest, only a real-time forgery risk on a later clock.
5. The IETF has already standardized the fix. ML-KEM and ML-DSA / SLH-DSA are defined for S/MIME’s underlying message syntax (RFC 9936, 9882, 9814) and for OpenPGP (RFC 9980).

Think of a locked box sent through the post. Locking the box directly with the recipient’s own heavy padlock would be slow, and a sender might be writing to a hundred people at once. So instead you throw the message in a strongbox, snap one fast combination lock on it, then seal the tiny combination slip inside a small envelope that only the recipient’s key can open. Encrypted email works exactly like that: the fast combination lock is AES on the message body, and the small envelope is the recipient’s public key wrapping the combination. The quantum problem is entirely about that small envelope. A quantum computer doesn’t grind on the strongbox; it reads the combination straight off the envelope, and anyone who kept a photograph of the sealed envelope years ago can open it the day the machine works.

What are S/MIME and OpenPGP?

S/MIME (Secure/Multipurpose Internet Mail Extensions) and OpenPGP are the two standardized ways to add end-to-end encryption and digital signatures to email, so a message is protected between the actual sender and the actual recipient rather than only between mail servers. Both deliver the same guarantees, confidentiality (only the recipient reads it), authenticity and integrity (the recipient knows who sent it and that nothing changed), and they package a message into a structure a compliant mail client can decrypt and verify.

The two come from different lineages:

1. S/MIME is specified by RFC 8551, the S/MIME version 4.0 message specification, and it builds directly on the Cryptographic Message Syntax (CMS). An S/MIME message is a CMS object, either SignedData for a signature or EnvelopedData for encryption, carried as a MIME body part. Because it rides on X.509 and CMS, S/MIME is baked into enterprise mail clients like Outlook and is the default for corporate, government, and regulated email.
2. OpenPGP is specified by RFC 9580, which replaced the older RFC 4880 and is the open standard implemented by GnuPG (GPG) and Proton Mail among others. It’s the standardized descendant of Phil Zimmermann’s original PGP from 1991. OpenPGP defines its own message and key formats rather than reusing X.509, and it’s the format favored where people distrust centralized authorities, journalists protecting sources, security researchers, and open-source signing.

Source: J. Schaad, B. Ramsdell, S. Turner, “Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification,” RFC 8551, April 2019, datatracker.ietf.org.

Source: P. Wouters, D. Huigens, J. Winter, Y. Niibe, “OpenPGP,” RFC 9580, July 2024, datatracker.ietf.org.

How do S/MIME and OpenPGP differ?

They differ most in how a sender comes to trust that a public key really belongs to the person named, which is the hard problem in any encryption system. S/MIME answers it with delegated authority, and OpenPGP answers it with peer endorsement, and almost every other practical difference (where each is used, how keys get provisioned, who administers it) falls out of that one choice.

1. S/MIME uses a hierarchical trust model. A Certificate Authority verifies an identity and issues an X.509 certificate binding that identity to a public key. A recipient’s client trusts the certificate because it chains to a CA already in its trust store, the same PKI mechanism behind TLS. That centralization is what makes S/MIME easy to deploy across an organization from the top down, and it’s also its single point of failure, since a compromised CA can vouch for a fraudulent key.
2. OpenPGP uses a decentralized web of trust. There’s no authority. A user endorses a key by signing it, and trust propagates through chains of people who have signed each other’s keys, so a key you’ve never seen becomes trustworthy because someone you already trust signed it. This removes the central authority entirely, at the cost of a steeper learning curve and no top-down provisioning. Many modern OpenPGP deployments soften this with Web Key Directory (key discovery over HTTPS) or trust-on-first-use, but the underlying model is peer endorsement.

The comparison, at a glance:

Dimension	S/MIME	OpenPGP (PGP)
Trust model	Hierarchical, delegated to a CA via X.509	Decentralized web of trust (users sign each other’s keys)
Defining standard	X.509 + CMS, RFC 8551	Its own key and message format, RFC 9580
Key provisioning	Top-down, a CA issues certificates	Bottom-up, users generate and cross-sign keys
Typical use	Enterprise, government, regulated mail (Outlook-native)	Journalists, activists, developers, software signing
Single point of failure	A compromised CA vouches for a bad key	A trusted key holder signs a bad key
Common tools	Outlook, enterprise mail gateways	GnuPG (GPG), Proton Mail

Underneath the trust models, the cryptographic operations are nearly identical: both hash-and-sign for authenticity and both wrap a symmetric content key for confidentiality, which is why the quantum exposure lands on both in the same two ways.

Where does the cryptography live in encrypted email?

Encrypted email uses two independent cryptographic jobs, and it’s worth pulling them apart because they face the quantum threat on completely different clocks. Both S/MIME and OpenPGP encrypt a message with the same layered construction rather than encrypting the whole body with a slow public-key algorithm:

1. A random symmetric key protects the body. The client generates a one-time content-encryption key and encrypts the message with a fast symmetric cipher, AES in practice. Symmetric encryption is only mildly affected by Grover’s algorithm, and a 256-bit key keeps a comfortable margin, so the body cipher is a strengthen-in-place item rather than a replacement.
2. A public-key algorithm wraps that symmetric key. The content key is then encrypted to each recipient’s public key so only they can unwrap it. In S/MIME that’s RSA key transport (RSA-OAEP) or an ECDH key agreement carried in CMS; in OpenPGP it’s RSA or ECDH over a curve like Curve25519. This wrapping step is the quantum-vulnerable one.
3. A digital signature proves origin. Separately, the message is signed with the sender’s private key, RSA or ECDSA in S/MIME, RSA or EdDSA in OpenPGP, so the recipient can verify who sent it and that it wasn’t altered. This is a digital signature, and it faces the quantum threat too, but as a forgery risk rather than a secrecy one.

So “is my encrypted email quantum-safe?” has two answers, one for the confidential half and one for the authenticity half. The key-wrapping half is harvestable and urgent; the signing half is a real-time forgery risk on a later clock. Everything downstream in this note follows that split.

Why is encrypted email a harvest-now-decrypt-later target?

Encrypted email is close to a textbook harvest-now-decrypt-later surface, because all three conditions that make HNDL bite are present at once: the ciphertext is collectible, the content stays sensitive for years, and the protection rests on public-key math a quantum computer will break. The attack needs nothing clever today, only patience:

1. The wrapped key is recoverable from a public key. A recipient’s encryption certificate or OpenPGP public key is, by design, published, on keyservers, in directories, in the signed emails they’ve already sent. A cryptographically relevant quantum computer running Shor’s algorithm recovers the matching private key from that public key, and with the private key it unwraps the content-encryption key on any message ever sent to that recipient.
2. Email is archived for years, so the ciphertext is waiting. Mail is one of the most heavily retained data types an organization holds, in mailboxes, server stores, backups, and compliance archives that are legally required to keep messages for many years. An adversary who captured or exfiltrated encrypted mail years ago, or who pulls it from a breached archive later, holds ciphertext that outlives the cryptography protecting it.
3. The content is exactly the long-lived kind. Legal strategy, M&A activity, source protection, health and financial records, government communication, the material people bother to encrypt in the first place is the material whose confidentiality has to last a decade or more. That’s the precise profile Mosca’s theorem flags as already exposed today.

That’s why encrypted email is on the front of the migration queue with TLS and VPN traffic, and for the same reason: the harvesting window is open now, and the only variable is how long the captured mail must stay secret. Anything encrypted and archived today under classical RSA or ECDH is living on borrowed time.

Source: Balaji et al., “Operationalising Post-Quantum TLS,” arXiv:2605.17955 (2026), on the measurable prevalence of harvestable classical key exchange in deployed systems, arxiv.org.

Is signed email exposed the same way?

No, and the difference is the whole HNDL-versus-Non-HNDL distinction. A digital signature on an email is a Non-HNDL exposure: forging one is worthless in advance and only pays off in real time, at the moment a recipient verifies it, so there’s nothing an attacker can usefully harvest and store. The clock is the arrival of the quantum computer, not today’s collection.

The mechanics still matter, because the signing keys are just as public and just as breakable:

1. The forgery needs a live machine. Only once a quantum computer can run Shor’s algorithm against a signer’s RSA or ECDSA public key can an attacker recover the private key and sign mail in that person’s name. Before then, a captured signed email is simply a verifiable record, not a liability.
2. The blast radius can still be large. A forged signed email from a CEO, a signed software release, or a forged S/MIME message chaining to a trusted CA is a convincing impersonation, and in the S/MIME case a broken CA key threatens every certificate it issued, the PKI-collapse scenario.
3. It migrates on a slower but real track. Because there’s no harvesting deadline, signature migration for email trails key-wrapping migration, but it still has to finish before the machine exists, since a forgery after the fact is undetectable.

The practical read: prioritize the encryption side of email for the harvesting clock, and treat the signing side as a real but later forgery problem weighted by whose key it is. High-value, long-trusted signing keys (an executive’s, a software publisher’s) belong near the front even without a harvesting deadline.

How do S/MIME and OpenPGP go post-quantum?

Both formats already have standardized post-quantum profiles, and the fix is the same shape as everywhere else in the transition: swap the vulnerable public-key pieces (ML-KEM for key wrapping, ML-DSA or SLH-DSA for signing) while keeping the symmetric body cipher. The IETF did the two formats in different working groups, and by 2026 much of it is finalized rather than draft:

1. S/MIME goes post-quantum through CMS. Because an S/MIME message is a CMS object, the post-quantum work lands in the CMS algorithm RFCs. RFC 9936 defines using ML-KEM to wrap the content-encryption key (via the KEMRecipientInfo structure), which closes the harvestable half. RFC 9882 defines ML-DSA signatures in CMS and RFC 9814 defines SLH-DSA signatures, which close the forgery half. Companion RFCs define the matching X.509 algorithm identifiers so certificates can carry the new keys.
2. OpenPGP goes post-quantum through RFC 9980. RFC 9980, “Post-Quantum Cryptography in OpenPGP” (June 2026), extends RFC 9580 with three algorithm families: a composite KEM pairing ML-KEM with elliptic-curve Diffie-Hellman for encryption, a composite signature pairing ML-DSA with EdDSA, and standalone SLH-DSA signatures.

Job	Classical (broken)	Post-quantum replacement	S/MIME (CMS)	OpenPGP
Key wrapping (HNDL)	RSA / ECDH	ML-KEM	RFC 9936	RFC 9980 (composite with ECDH)
Signing (Non-HNDL)	RSA / ECDSA / EdDSA	ML-DSA, SLH-DSA	RFC 9882, RFC 9814	RFC 9980 (composite ML-DSA, standalone SLH-DSA)
Message body	AES-256 (keep)	AES-256 (keep)	unchanged	unchanged

Source: J. Prat, M. Ounsworth, D. Van Geest, “Use of ML-KEM in the Cryptographic Message Syntax (CMS),” RFC 9936, March 2026, datatracker.ietf.org.

Source: R. Housley, J. Gray, T. Ito, S. Turner, “Use of the ML-DSA Signature Algorithm in the CMS,” RFC 9882, October 2025, datatracker.ietf.org.

Source: R. Housley, S. Fluhrer, P. Kampanakis, B. Westerbaan, “Use of the SLH-DSA Signature Algorithm in the CMS,” RFC 9814, July 2025, datatracker.ietf.org.

Source: S. Kousidis, J. Roth, F. Strenzke, A. Wussler, “Post-Quantum Cryptography in OpenPGP,” RFC 9980, June 2026, datatracker.ietf.org.

The catch is the same one that governs the rest of applied PQC. A profile existing in an RFC is a different thing from every mail client, gateway, and archive supporting it, and both the sender’s and the recipient’s software have to speak the new algorithms for a given message to actually be protected. Migrating email is a client-and-directory rollout, and it’s exactly what a CBOM tracks and what crypto-agility is meant to make painless the next time the algorithm changes.

Has this happened before?

Yes, and it’s the origin of OpenPGP itself. When Phil Zimmermann released the first version of PGP in 1991, he built the web of trust deliberately, as a way to give ordinary people strong email encryption without asking permission from any central authority, because a central authority was precisely who he expected to be pressured. He was right about the pressure. Strong cryptography was classified under U.S. export rules as a munition, and after PGP spread worldwide over the early internet, Zimmermann spent roughly three years, from 1993 until the case was dropped in early 1996, under U.S. federal criminal investigation for “exporting” it. He answered the export ban by publishing PGP’s source code as a printed book through MIT Press, on the argument that a book is protected speech in a way software was not.

The line to today is direct. The trust-model split at the heart of this note, delegated CA authority versus decentralized peer endorsement, is not a technical accident; it’s a political choice about who gets to decide a key is genuine, and Zimmermann chose decentralization on purpose. The quantum transition doesn’t change that choice. It changes the algorithms underneath both trust models, and the same web of trust he designed in 1991 now carries ML-KEM and SLH-DSA keys under RFC 9980.

Source: Simon Singh, The Code Book, chapter on “Pretty Good Privacy” and the Zimmermann export case.

Common misconceptions

1. “S/MIME and OpenPGP are compatible, so I can pick either.” They aren’t interoperable. An S/MIME client can’t read an OpenPGP-encrypted message or vice versa, because the key and message formats differ. Sender and recipient have to share a format, which is a big part of why encrypted email adoption stayed fragmented.
2. “Encrypted email isn’t a quantum problem because the body uses AES.” The AES body is fine. The exposure is the RSA or ECDH step that wraps the AES key to the recipient, and that wrapping is what a quantum computer unwraps years later.
3. “The signing side is the urgent one.” It’s the reverse for email. Signature forgery is Non-HNDL and needs a live quantum computer, so there’s nothing to harvest. Encrypted, archived mail is harvestable today, which makes the encryption side the one to move first.
4. “OpenPGP has no single point of failure because there’s no CA.” The web of trust moves the failure rather than removing it. A key that many people trust and sign can vouch for a fraudulent key just as a compromised CA can, so trust concentration exists in both models, in different shapes.
5. “Post-quantum email is still years away in the standards.” The standards are largely finished. ML-KEM, ML-DSA, and SLH-DSA are already specified for both CMS/S/MIME and OpenPGP as published RFCs; the lag now is client and gateway support, not the specification.
6. “Deleting old email closes the exposure.” Only for copies you actually control. Messages already captured by an adversary, or held in a counterparty’s archive or in a backup outside your control, stay exposed regardless of what you delete on your side.

Questions people ask

Is my encrypted email at risk from quantum computers right now? The confidential half is exposed to harvesting today. If sensitive mail was encrypted with classical RSA or ECDH key wrapping and it sits in an archive an adversary could reach, a future quantum computer can decrypt it retroactively. The urgency scales with how long that mail must stay secret.

Which should I use, S/MIME or OpenPGP? It depends on trust model and ecosystem, not on security strength, since both offer the same post-quantum algorithms now. S/MIME fits organizations that already run a CA and want top-down provisioning in clients like Outlook; OpenPGP fits people who need decentralized trust and cross-platform tooling like GnuPG. Whichever you pick, the migration story is the same.

Do S/MIME and OpenPGP work together? No. They use incompatible key and message formats, so a sender and recipient must use the same standard. There’s no automatic bridge between an X.509-based S/MIME identity and an OpenPGP key.

What’s the post-quantum replacement for encrypted email? ML-KEM replaces the classical key wrapping that protects confidentiality, and ML-DSA or SLH-DSA replaces the signature. They’re standardized for S/MIME via the CMS RFCs (9936, 9882, 9814) and for OpenPGP via RFC 9980.

Why does encrypted email get called a harvest-now-decrypt-later target specifically? Because email is retained for years in mailboxes, backups, and compliance archives, and the key that protects each message is wrapped with breakable public-key math. That combination, long-lived ciphertext plus a quantum-vulnerable key, is the exact recipe for HNDL.

Does a bigger RSA key protect my email until I migrate? Barely. Increasing an RSA key from 2048 to 4096 bits buys almost nothing against Shor’s algorithm, which scales past both. The fix is switching the key-wrapping algorithm to ML-KEM, not enlarging the classical one.

Is the web of trust more or less quantum-safe than a CA hierarchy? Neither. The trust model decides how you validate a key, and the quantum threat is about the algorithm inside the key, so both models are equally exposed to classical algorithms and equally fixed by moving to ML-DSA or SLH-DSA. RFC 9980 upgrades the web of trust’s algorithms without touching its structure.

What do I actually have to change to migrate? The mail clients and gateways on both ends have to support the new algorithms, the certificates or keys have to be reissued with ML-KEM / ML-DSA keys, and directories or keyservers have to publish them. It’s a client-and-key-provisioning rollout rather than an application rewrite, and it belongs in the same CBOM as the rest of your cryptographic estate.

---

Everything here is the map, given freely. When your team needs its own encrypted-mail estate found, its harvestable archives prioritized, and a post-quantum path sequenced across every client, gateway, and directory, that’s the work I do. Request an alignment briefing.

Last verified 2026-07-09 · Maintained by Addie LaMarr, LaMarr Labs.