For most of my life as a user, GPG was the quiet background of trust on the internet. Keys were 4096-bit RSA, and that was simply how encrypted mail worked, the same way letters were stamped and checks were signed. The assumption beneath it was comforting: that the math would stay hard forever.
Around 2019 that assumption began to sound less like confidence and more like hope. Shor’s algorithm had been known since 1994, but a working quantum computer was always “twenty years away.” That number stopped moving, and eventually people stopped repeating it.
“Harvest now, decrypt later” is not a conspiracy theory. It is a threat model.
Adversaries can record ciphertext today, park it in a database, and break it the day a fault-tolerant machine arrives. If your messages are sensitive for a decade, the “now” is already overdue. That was the argument that made me stop postponing.
Why privacy demands this
It is worth asking why any of this matters, because "post-quantum" can sound like a hobby. The honest answer is privacy, in the plainest sense: the right to say something to one person and not have it become a matter of record for anyone else.
The threat is not exotic. Adversaries record encrypted traffic today and keep it. Mail, messages, documents in the cloud, everything sent over the internet is capturable by anyone with access to the wire. If the encryption that protects it rests on RSA or ECC, a future quantum computer can undo it retroactively. "Harvest now, decrypt later" turns a private conversation of 2026 into a public record of 2040.
Privacy is what makes that unacceptable. It is not about having something to hide. It is about the long confidentiality of a life: medical records that stay between you and your doctor, legal correspondence that stays between you and your lawyer, drafts, diaries and disagreements that stay yours. Most of that data is expected to stay private for decades, far longer than the useful life of a classical key.
Post-quantum cryptography is not a niche of paranoia. It extends the same promise encryption made in the 1990s into a future where the mathematics changes. The people who need it most are not cryptography enthusiasts. They are journalists, dissidents, whistleblowers, lawyers, doctors, and anyone whose safety depends on a conversation staying private long after it ends.
The boring choice
Post-quantum is a crowded zoo, but two designs rose to the top of NIST’s standardization effort: ML-KEM (CRYSTALS-Kyber) for key encapsulation and ML-DSA (CRYSTALS-Dilithium) for signatures. Both are lattice-based, which sounds exotic until you realize it is just linear algebra with very large matrices and a little noise thrown in.
The important part for someone replacing GPG is that the shape of the system stays familiar. Encryption is still “encapsulate a shared secret with the recipient’s public key.” Signing is still “prove knowledge of a private key.” The pain is purely mechanical: keys are bigger, ciphertexts are bigger, and the algorithms are new enough that you should treat their first implementations with suspicion.
What changed in practice
In my replacement, pqp, a key pair is no longer one
RSA blob but two objects generated together, a Kyber encapsulator
and a Dilithium signer:
$ pqp gen-key -u "AJ. Díaz" --kem ML-KEM-768 --dsa ML-DSA-65
✓ Key ring created at ~/.local/share/pqp/keys/
✓ Passphrase set
→ public key 8f3a21c9 saved as pqp-public.der
→ secret key 8f3a21c9 wrapped and encryptedA few observations from building it. First, generation is fast. Lattice keys pop out in milliseconds. Second, the public key is roughly four times the size of an RSA key, which is fine for personal mail and a genuine cost for directories with millions of entries. Third, and most pleasantly, the failure modes are the same as always: a lost secret key is a lost message, no matter how fancy the lattice.
The options that already exist
Replacing GPG does not mean writing a crypto library from scratch, and it does not force anyone onto my tool. The ecosystem has real choices now.
GnuPG itself. The current releases support
Kyber-based hybrid encryption and, more recently, the FIPS 203
(ML-KEM) and FIPS 204 (ML-DSA) algorithms natively. If you want the
smallest possible change, you can keep using gpg and
simply generate post-quantum or hybrid keys. Your passphrase model,
your agent, and your scripts all keep working.
The OpenPGP ecosystem. The IETF crypto refresh
introduced keys designed for hybrid post-quantum cryptography, and
Sequoia-PGP with its sq command line already issues
and consumes them. This is the path that keeps keys interoperable
with the wider OpenPGP world.
The infrastructure underneath. OpenSSL 3.5 ships ML-KEM and ML-DSA for TLS, and liboqs from the Open Quantum Safe project provides reference-quality implementations many applications build on. The rest of the stack is moving whether you touch it today or not.
pqp, my own tool. pqp is the choice
when you want GPG's muscle memory, a familiar file format, and a
single small binary. It is deliberately conservative: ML-KEM-768
and ML-DSA-65 by default, self-describing files, and no key server
or agent to babysit.
Whichever you pick, the point is that the option exists at all. Five years ago it did not.
A dependency on someone else's correctness
There is a cost to building on libraries, and it deserves to be
stated plainly. Every cryptographic operation in pqp
is implemented by the RustCrypto project's crates: ml-kem,
ml-dsa, chacha20poly1305, argon2
and sha3. I did not write that code, and I cannot
audit all of it.
That means the security of pqp rests, in part, on the
correctness of code I do not control. If a flaw is ever found in
one of those crates, every tool built on it inherits the flaw.
Every project that uses libraries shares this risk, but
cryptography concentrates it: a single bug in a KEM implementation
can defeat the whole system, however carefully the command line
around it is written.
There are ways to live with it. Pin exact crate versions and audit
the ones you depend on. Watch the RustSec advisory database, which
is how I caught RUSTSEC-2026-0164 and avoided the unmaintained
pqcrypto umbrella crate. Prefer pure-Rust
implementations from reputable projects over wrappers around native
code you cannot reproduce. And keep the dependency list short,
because every line of foreign code is a line of potential failure.
None of this makes pqp safer than GnuPG's own
implementation, which has been scrutinized for thirty years. It
makes it transparent. You can see exactly which crates, at which
versions, produced the binary you run, and rebuild it from source.
Transparency is not the same as security. It is the precondition
for it.
The migration story is the real work
Cryptography is a rare discipline where the upgrade path matters as much as the cipher. GPG survived three decades not because RSA was unbeatable but because keys were portable, signatures were verifiable across generations, and a file encrypted in 1998 could still be opened in 2026.
So the file format in pqp is self-describing,
an algorithm string like ML-KEM+XChaCha20-Poly1305+ZSTD+BASE64
travels with the payload. Any future reader can see what was used,
look it up, and open the file. If I am wrong about a detail, a
migration tool can find every file that used it. That property is
worth more than any single algorithm choice.
Where I landed
Post-quantum will not save you from a bad password or a stolen laptop. What it does is remove one of the longest timers in the room. I sleep slightly better knowing the ciphertexts I produce today will not silently open in 2035. That is a modest, boring kind of victory, and it is exactly the kind worth shipping.
The full source lives on GitHub. If you are migrating, start with keys that have a long lifetime. That is where the time bomb is.