The closing article of the series: every specification, paper, attack disclosure, book, talk, tool and community resource worth your time, organized by what you are trying to accomplish rather than by type. Includes three learning roadmaps — implementer, researcher, security engineer — and an honest note about which widely-recommended resources are now out of date and will teach you the wrong thing.
Read this first. Most OpenPGP material on the internet predates RFC 9580 (2024) and RFC 9980 (2026), and a great deal of it predates EFAIL (2018) and the SKS collapse (2019). Tutorials that tell you to upload to the SKS pool, that describe the MDC as adequate integrity protection, or that treat the Web of Trust as a working global system are teaching you a world that no longer exists. Check the date on everything.
1. Specifications — start here
1.1 Core
- RFC 9580 — OpenPGP (2024) — the current standard. Obsoletes RFC 4880. Read §4 (packet syntax), §5 (packet types), §10 (message grammar) first; the rest is reference. Covered throughout this series.
- RFC 9980 — Post-Quantum Cryptography in OpenPGP (June 2026) — composite ML-KEM+ECDH, ML-DSA+EdDSA, standalone SLH-DSA, and the KEM combiner. See Article 6.
- RFC 4880 — OpenPGP Message Format (2007, obsoleted) — still what most deployed software implements. You must know it to interoperate, even though you should not build to it.
- LibrePGP specification — the competing branch GnuPG follows. Read it specifically to understand where your ciphertext will fail to decrypt.
- RFC 3156 — MIME Security with OpenPGP — PGP/MIME. Essential if you touch email, and the layer where several EFAIL variants actually operated.
- RFC 7929 — DANE OPENPGPKEY — DNS-based key discovery.
1.2 Active drafts worth tracking
- draft-koch-openpgp-webkey-service — Web Key Directory — the de-facto key discovery mechanism despite never having become an RFC. See Article 5.
- draft-gallagher-openpgp-signatures — clarifies signature semantics and signed-message structure where RFC 9580 is terse. Valuable for anyone implementing verification.
- draft-bre-openpgp-samples — canonical example keys and certificates. Use these as test vectors rather than generating your own.
- draft-ietf-keytrans-architecture — Key Transparency architecture; the OpenPGP WG intends to build on it.
- IETF OpenPGP WG document list — the authoritative source for what is currently in flight.
1.3 Supporting cryptographic standards
- RFC 9106 — Argon2 — the S2K KDF from Article 2.
- RFC 7253 — OCB — the recommended AEAD mode.
- RFC 8032 — EdDSA (Ed25519/Ed448)
- RFC 7748 — X25519/X448
- FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA) — the post-quantum primitives RFC 9980 composes.
2. Research papers and attack disclosures
2.1 The essential five
| Paper | Venue · Year | Why it matters |
|---|---|---|
| Efail: Breaking S/MIME and OpenPGP Email Encryption using Exfiltration Channels Poddebniak, Dresen, Müller, Ising, Schinzel, Friedberger, Somorovsky, Schwenk | USENIX Security 2018 | The single most important OpenPGP security paper. CFB gadgets, three integrity bypasses, practical plaintext exfiltration. Article 3. |
| SoK: Why Johnny Can't Fix PGP Standardization | 2020 | Systematizes how the standardization process itself produced the ambiguities that became vulnerabilities. Essential context for anyone who wonders why the format is like this. |
| An Attack on CFB Mode Encryption As Used By OpenPGP Mister & Zuccherato | IACR ePrint 2005 | The quick-check oracle. The clearest small example of "any observable check on unauthenticated plaintext is an oracle." |
| Challenging the Trustworthiness of PGP: Is the Web-of-Trust Tear-Proof? Barenghi et al. | ESORICS 2015 | Graph-theoretic analysis showing the WoT strong set depends on a small number of high-degree nodes. The quantitative basis for Article 5's conclusions. |
| SHA-1 is a Shambles Leurent & Peyrin | USENIX Security 2020 | Practical chosen-prefix SHA-1 collision. Bounds exactly how worried to be about v4 fingerprints. Article 2. |
2.2 Further reading
- SHAttered — The first collision for full SHA-1, Stevens et al., CRYPTO 2017 — the precursor to Shambles.
- Evil32: Short Key IDs are bad news — colliding 32-bit key IDs for the entire WoT strong set. Not a formal paper; more persuasive than most.
- Why Johnny Can't Encrypt, Whitten & Tygar, USENIX Security 1999 — the foundational usable-security paper. Dated in specifics, still correct in its central finding.
- Why Johnny Still, Still Can't Encrypt (Ruoti et al.) — the follow-ups, confirming the problem did not go away.
- Preventing EFail Attacks with Client-Side WebAssembly — a concrete mitigation architecture; useful as a worked example of defending the rendering boundary.
- IACR ePrint archive — search for "OpenPGP" periodically; this is where new analysis lands first.
2.3 Vulnerability disclosures worth studying
| Identifier | What | Lesson |
|---|---|---|
| CVE-2018-12020 — SigSpoof | Status-line injection via unescaped Literal Data filename | Never multiplex machine-readable and human-readable output. Article 4. |
| CVE-2019-13050 — SKS flooding | Certificate poisoning, permanent and unfixable | Append-only + unauthenticated writes + unbounded size = DoS primitive. Article 5. |
| CVE-2025-47934 — OpenPGP.js spoofing | Message spoofing via API-shape confusion | Memory safety does not prevent verification-logic bugs. |
| Hansen — SKS Under Attack | First-hand account by a target | Read this before designing any append-only public store. |
3. Books
There is no current, good, technical book about OpenPGP. The format-specific books are all pre-2010 and describe a world before AEAD, before EFAIL, before the SKS collapse, and before RFC 9580. The RFC is the book. What follows is what to read for the surrounding competence instead.
| Book | Author | Read it for |
|---|---|---|
| Real-World Cryptography | David Wong | Start here if you need the surrounding crypto competence. Modern, practical, tells you what to use and what to avoid. Covers AEAD, KDFs, and PQC at the right level for this series. |
| Serious Cryptography (2nd ed.) | Jean-Philippe Aumasson | One layer deeper into primitives and why they fail. The natural follow-up to Wong. Second edition includes post-quantum. |
| Cryptography Engineering | Ferguson, Schneier, Kohno | How cryptographic systems fail, as distinct from primitives. The mindset behind every "checklist" section in this series. |
| Security Engineering (3rd ed.) | Ross Anderson | The architectural backstop. Chapters on trust, PKI and usability directly illuminate why the WoT failed. Freely available online. |
| PGP & GPG: Email for the Practical Paranoid | Michael W. Lucas | Operational usage, well written — but 2006. Everything about keyservers and integrity is obsolete. Read for workflow intuition only. |
| PGP: Pretty Good Privacy | Simson Garfinkel | 1994. Historical interest — the development story and the early format. Do not implement from it. |
| A Graduate Course in Applied Cryptography | Boneh & Shoup | Free. The rigorous treatment of the KEM/DEM framework, AEAD security definitions, and signature security notions that RFC 9980's composite constructions assume you know. |
4. Talks and video
- Efail — USENIX Security 2018 presentation — Poddebniak's talk is clearer than the paper on gadget mechanics. Slides also available directly. Watch before reading the paper.
- Sequoia PGP: Rethinking OpenPGP Tooling — Neal Walfield, FOSDEM 2024 — why a new implementation was built and what it does differently. The clearest statement of the modern design position.
- FOSDEM Security & Encryption devroom archives — the most reliable annual venue for OpenPGP implementation talks. Search past years for "OpenPGP", "Sequoia", "GnuPG".
- CCC media archive — PGP talks — Chaos Communication Congress presentations, including the EFAIL follow-up sessions. Consistently high technical quality.
- USENIX Security channel — every paper in §2 that appeared at USENIX has a recorded talk here.
- IACR video archive — CRYPTO, EUROCRYPT and CHES talks, including the SHA-1 collision presentations.
5. Courses
- Cryptography I — Dan Boneh, Stanford — free. The standard foundation. Weeks on authenticated encryption and public-key encryption map directly onto Articles 3 and 6.
- Cryptopals Crypto Challenges — the single highest-value exercise for this material. Set 2 and 3 build CBC/CTR malleability and padding-oracle attacks by hand, which is precisely the intuition EFAIL requires. Do these before reading the EFAIL paper.
- CryptoHack — gamified, broader coverage including lattices and post-quantum. Good complement to Cryptopals.
- MIT 6.857 — Computer and Network Security — course materials and reading lists are public.
6. Implementations and tools
6.1 Libraries
| Project | Language | Standard | Use when |
|---|---|---|---|
| Sequoia | Rust | RFC 9580 | New systems. Memory-safe, audited, explicit policy engine. The reference for correctness. |
| GnuPG / GPGME | C | 4880 + LibrePGP | Interoperating with existing deployments. Use GPGME, never CLI parsing. |
| RNP | C++ | 4880 + AEAD | Thunderbird integration or existing C++ stacks. |
| OpenPGP.js | JavaScript | 4880 + parts of 9580 | Browser or Node. Read the verification API docs carefully. |
| GopenPGP | Go | 4880 + extensions | Go services. |
| rPGP | Rust | 4880 + 9580 work | Alternative Rust implementation; used in some Delta Chat / messaging contexts. |
6.2 Command-line and inspection
# Packet inspection — run at least two of these on the same input gpg --list-packets --verbose message.pgp sq packet dump --hex message.pgp # Sequoia; stricter, reports policy issues pgpdump -i -l -m message.pgp # most readable annotations # Armor handling gpg --dearmor < message.asc > message.bin sq packet dearmor message.asc # Certificate inspection sq inspect --certifications cert.pgp gpg --list-packets < cert.pgp | grep -c ':signature packet:' # flooding check # WKD verification for a domain you operate gpg-wks-client --check user@example.org curl -sI https://openpgpkey.example.org/.well-known/openpgpkey/example.org/policy
- GnuPG tool suite — includes
gpg-wks-clientandgpg-wks-serverfor WKD deployment. - Sequoia project suite —
sq,sqop,sq-wot, plus the Chameleon GnuPG-compatible drop-in. - pgpdump — long-standing standalone packet dumper.
6.3 Test suites and interoperability
- Sequoia OpenPGP Interoperability Test Suite — the most useful single resource in this section. Runs a large corpus against every major implementation and publishes a matrix of who accepts what. Consult it before assuming any behavior is portable.
- draft-bre-openpgp-samples — canonical test keys and certificates.
- Sample artifacts repositories — known-good and known-bad inputs for parser testing.
- openpgp.org standard page — implementation compatibility overview.
7. Community and staying current
- IETF openpgp@ mailing list archive — where the standard is actually argued. The schism is documented here in primary form.
- IETF OpenPGP working group — charter, milestones, and current documents.
- gnupg-devel — GnuPG development discussion.
- Sequoia mailing lists
- pgpkeys.eu blog — keyserver ecosystem status reporting.
- Sequoia blog — consistently good technical writing on implementation issues.
- GnuPG blog — the other side's position, stated directly.
8. Learning roadmaps
Fig. 1 — Different starting points, same destination. The interoperability test suite is the reality check for all three.
8.1 Implementer — "I am building something with OpenPGP"
| Step | Do | Time |
|---|---|---|
| 1 | Cryptopals sets 1–3. Build a padding oracle by hand. | 2–3 weeks |
| 2 | Read RFC 9580 §4, §5, §10. Dump real messages with two tools and reconcile. | 1 week |
| 3 | Read this series' Articles 1–4 alongside the RFC. | 1 week |
| 4 | Write a read-only packet parser in a memory-safe language. Do not implement crypto. | 2 weeks |
| 5 | Run it against draft-bre-openpgp-samples and malformed inputs. Fix every panic. | 1 week |
| 6 | Read the EFAIL paper and SigSpoof advisory. Re-audit your parser against both. | 3 days |
| 7 | Read Sequoia's source for the layers you implemented. Compare decisions. | 1 week |
| 8 | Check the interop matrix; pick your dialect explicitly and document it. | 1 day |
Then stop and use a library. The point of the exercise is to be able to evaluate and use one correctly, not to ship your own.
8.2 Researcher — "I want to work on this"
- Boneh & Shoup for the KEM/DEM and AEAD security definitions RFC 9980's composites assume.
- The five essential papers in §2.1, in the order listed — EFAIL first, because it motivates the rest.
- RFC 9580 in full, then RFC 9980, then the LibrePGP spec, reading for the differences.
- The IETF openpgp@ archive around 2022–2024 for the schism as it happened.
- Open problems worth attention: formal analysis of RFC 9980's KEM combiner in the multi-user setting; automated detection of grammar-confusion classes across implementations; usable key transparency for OpenPGP; quantifying WoT residual value post-SKS; parser differential testing across the 4880/9580/LibrePGP dialects.
8.3 Security engineer — "I own a deployment"
- Inventory. Which implementation, which version, which algorithms, which key versions, and who consumes your artifacts.
- Kill the known-bad. No SED (tag 9) acceptance, no S2K usage 255, no RSA <3072, no DSA, no short key IDs anywhere in tooling or UI.
- Fix the interface. If anything shells out to
gpgand parses output, that is your highest-priority finding. Move to GPGME or a library. - Bound the inputs. Certification caps, size caps, decompression limits, nesting depth limits.
- Fix distribution. WKD on your domain; keys.openpgp.org; nothing depending on the SKS pool.
- Plan the migration. Ed25519/X25519 now; ML-KEM-768+X25519 for archival where you control both ends (Article 6).
- Instrument. Log algorithm and version usage, or you cannot measure any of the above.
9. What to be skeptical of
| Resource type | Problem |
|---|---|
| Pre-2018 tutorials | Predate EFAIL. Will describe the MDC as sufficient and may not mention SED downgrade at all. |
| Pre-2019 keyserver advice | Tells you to upload to the SKS pool. Actively harmful now. |
| Anything saying "OpenPGP-compatible" without qualification | Meaningless post-schism. Ask which: 4880, 9580, or LibrePGP. |
| "Web of Trust" tutorials framed as a global system | Describes an aspiration, not a deployed reality. Fine as an internal mechanism. |
Blog posts that shell out to gpg and parse stdout | Teaching the SigSpoof bug class as a pattern. |
| PGP-is-dead essays | Usually correct about the usability critique, usually silent on what to use for the file and archive encryption use cases OpenPGP still serves. |
10. Closing the series
Six technical articles and a map. The through-line, if there is one: almost every OpenPGP failure in thirty years has been at a boundary rather than in a primitive. The ciphers held. The signatures were mathematically sound. What broke was the boundary between decryption and integrity checking (EFAIL), between the verification result and the interface reporting it (SigSpoof), between what a user sees and what was signed (cleartext canonicalization), between a certificate and its unbounded appendable signatures (SKS), and between two committees who could not agree on a packet tag (the schism).
That is the useful generalization to carry out of this material into whatever you build next. The cryptography is the part most likely to be correct. The interfaces around it are where you should spend your review time.
FAQ
What is the single best resource if I only read one thing?
RFC 9580, sections 4, 5 and 10. It is dense but it is the only current, complete, authoritative description of the format. Everything else is commentary — including this series.
Should I learn OpenPGP in 2026, or is it obsolete?
For interactive messaging, use Signal — the forward-secrecy and usability arguments are decisive. OpenPGP remains the standard for signed software releases, long-term archival encryption, non-interactive machine-to-machine encryption, and email where regulatory or institutional requirements dictate it. Those are real, ongoing use cases, and the format's engineering history is independently valuable as a case study.
Which implementation should I read the source of?
Sequoia. It is the most readable modern codebase, tracks RFC 9580 closely, and its explicit policy engine makes the security decisions visible in code rather than buried in defaults. Read its parser alongside RFC 9580 §4 and the two will teach each other.
How do I keep up after this?
Follow the IETF openpgp@ archive and the Sequoia and GnuPG blogs, and re-check the interoperability test suite when you change anything. Those three cover the standard, both sides of the schism, and reality respectively.
The full series
- 1 — The wire format : packet framing, six length encodings, tags, MPI vs native, the message grammar, armor.
- 2 — Keys, fingerprints, and secret-key protection : certificate structure, v4/v6, SHA-1 fingerprints, key-ID collisions, binding and back signatures, S2K through Argon2.
- 3 — Confidentiality : OpenPGP CFB, the quick-check oracle, the MDC's structural failure, EFAIL gadgets, SEIPDv2 chunked AEAD.
- 4 — Signatures : packet anatomy, hashed vs unhashed, hash input and trailer, signature types, cleartext canonicalization, SigSpoof.
- 5 — Trust and distribution : certification semantics, WoT propagation, the SKS collapse, keys.openpgp.org, WKD, DANE, key transparency.
- 6 — Post-quantum and the schism : RFC 9980 composites, the KEM combiner, SLH-DSA, LibrePGP vs RFC 9580, implementation comparison, migration plan.
- 7 — The resource map : this article.