This is Part 1 of three. Part 2 (coming soon) covers why this matters now. Part 3 (coming soon) is a command-line walkthrough of wallet keys.

Privacy is a right. Your keys are your data. Math beats promises. Don’t trust, verify. Apply that same standard to the new post-quantum algorithms: understand what they do before you trust them with anything.

The analogy

Think of cryptography as locks on doors.

• An algorithm is a lock design: the shape of the pins.
• A key is the metal that fits that design.
• Crypto-agility means you can change the lock design without tearing out the door. New algorithm, same system.
• A hybrid means two locks on the same door. A thief has to open both.

I use those words the same way through this series. For the operational version, see Assume the Math Will Move.

Two jobs: key exchange and signatures

Public-key crypto does two different jobs.

Key exchange is how two strangers agree on a shared secret without meeting. That secret then locks their messages. TLS does this when you visit a website. SSH does it when you log into a server.

Signatures prove it was you. You hold a private key. Everyone can check a matching public key. Bitcoin, Ethereum, and software updates all rely on this.

A hash function can help build signatures. It cannot do key exchange by itself. That limit is mathematical. Keep it in mind when someone says “just use hashes for everything.”

Hash functions: a one-way blender

A hash function is a blender with three habits:

1. Same input, same fingerprint.
2. One tiny change scrambles the result.
3. You cannot run it backwards.

We use hashes for integrity checks, blockchain addresses, and as building blocks inside bigger schemes. SHA-256 and SHA-3 are common examples. Quantum computers do not break hashes the way they break RSA and elliptic curves; they mostly push us toward longer outputs. More on that in Part 2.

What we use today: elliptic curves

Most of the internet and most blockchains still run on elliptic-curve cryptography.

• ECDSA and Ed25519 are signature schemes. Bitcoin and Ethereum wallets use secp256k1 with ECDSA. SSH often uses Ed25519.
• X25519 is key exchange. TLS 1.3 and modern SSH lean on it.

These are fast and the keys are small. That is why they won. They are also on the wrong side of a future large quantum computer. Excellent locks against today’s thieves. Not the locks we want for the next few decades alone.

Lattices: the main new federal standards

Lattice crypto hides secrets in high-dimensional grids. The honest party knows a shortcut. Everyone else sees a haystack.

NIST standardized two lattice schemes in August 2024:

• ML-KEM (FIPS 203): key encapsulation. The workhorse for hybrid TLS and SSH (for example X25519MLKEM768).
• ML-DSA (FIPS 204): signatures.

Keys and signatures are larger than elliptic curves, but still practical for most network protocols. Lattices are the default post-quantum choice for key exchange today. They are also the family getting nervous attention from people watching AI-accelerated math; that is a Part 2 story, not a known break.

Hash-based signatures: boring on purpose

Hash-based signatures build signing out of the blender. No lattices. No elliptic curves. Just hashes and careful bookkeeping.

SLH-DSA (FIPS 205) is the federal standard, based on SPHINCS+. Related ideas include WOTS (Winternitz one-time signatures). Signatures are bigger and slower than ML-DSA. That is the trade for relying on almost nothing beyond hash security.

A one-time hash signature (Lamport)

Here is the simplest version. Too large for daily use; perfect for intuition.

1. Alice picks a pile of random secret coins (private key).
2. She blends each coin into a fingerprint and publishes the fingerprints (public key).
3. To sign a message, she blends the message, looks at its bits, and reveals the secret coins those bits select.
4. Bob blends the revealed coins and checks that the fingerprints match Alice’s list.

Use those secrets once. Sign a second message and you leak overlap; a forger can stitch pieces together. SPHINCS+ (and SLH-DSA) wrap a tree of one-time keys so you can sign many times safely. The cartoon is the Lamport core; the standard is that core plus scaffolding.

Hashes can do this signature job. They still cannot do key exchange alone.

Code-based: Classic McEliece and HQC

Code-based crypto hides a message by adding noise to an error-correcting code. The secret holder can clean the noise.

• Classic McEliece dates to 1978 roots, is conservative, and has very large public keys with small ciphertexts. A specialist tool.
• HQC is a newer code-based key encapsulation scheme. NIST selected it as an additional algorithm, which matters if you want a second family for hybrids.

Different math from lattices is the point. Diversity of lock designs avoids a single failure mode.

Quick comparison

What to remember

Lock designs are algorithms. Keys fit them. Hybrids put two designs on one door. Agility lets you swap designs without rebuilding the house. Key exchange and signatures are different jobs. Hashes are a one-way blender: great for fingerprints and for certain signatures, useless alone for agreeing on a secret.

Next up, coming soon: the problem those locks are meant to solve. Then Part 3 puts wallet keys on the command line so you can feel what “changing the lock” actually breaks.

Views are my own and do not represent my employer. Nothing here is financial advice.

That is a sober take, and most of it is right. Where I land is one word: agility. If the math under our feet can move faster than we planned, the winning property of a system is how quickly and safely it can change what it runs on. Picking the perfect algorithm matters less than that.

This is my first post here, so a quick note on where I come from. I’m a cypherpunk at heart. Privacy is a right, your keys are your data, and math beats promises. Don’t trust, verify. That applies to Vitalik’s argument too, so let’s take it seriously.

The threat: AI as cryptanalyst

Vitalik’s threat model is clean. Factoring naively takes 2^(n/2) time, but decades of work produced the number field sieve and cut that to 2^O(n^(1/3)), “which is why RSA keys and signatures need to be ~400 bytes (and not 64 bytes).” His question: what if there are similar “skeletons in the closet” for elliptic curves and lattices that humans haven’t found, but AI soon will?

He goes further than most people are willing to: “So far most people have been in the mode of thinking ’elliptic curves broken, hashes safe, lattices safe’. But there is a good chance that the concrete security of lattices will take serious hits from the next two years of AI math.” He also notes AI is another reason ECDSA “might fall even faster than expected.”

To be clear about what this is: an informed estimate, which he labels as his “own personal views.” No known attack breaks ML-KEM or ML-DSA today. But I don’t need a known attack to act. Cryptanalysis only ever gets better, and the record shows margins shrinking in steps, not smoothly. If AI compresses research timelines, the rational move is to assume your margins erode faster than your roadmap assumed, and to plan for it.

We already have a fresh example that has nothing to do with AI. On September 29, Germany’s BSI published notes on Classic McEliece, one of the oldest public-key schemes around, saying it “should currently no longer be used in new developments” after new cryptanalysis lowered key-recovery estimates. BSI is clear the results “do not enable a practical attack” on the recommended parameters. Still, a scheme with nearly five decades of scrutiny got repriced in a few months. BSI drew the same lesson I do: the results “underline how important it is to pay attention to crypto-agility during the migration because cryptanalytic advances can never be ruled out.”

Agility beats monoculture

Here is where I add a layer to Vitalik’s view rather than disagree with it. For Ethereum, he backs the lean roadmap’s “hash-only” direction: “no lattices, no ML-DSA, no Falcon,” with signatures that are “all hash-based, either WOTS or SPHINCS-.” For lattices you can’t avoid, he suggests being “much more paranoid on param sizes,” and floats multiplying key sizes by 10 for anything meant to be long-term secure.

For signatures, that reasoning is strong, and the rest of the world isn’t starting from zero. Hash-based signatures already have a federal standard: FIPS 205 (SLH-DSA), based on SPHINCS+, published August 13, 2024 alongside FIPS 203 (ML-KEM) and FIPS 204 (ML-DSA).

But Vitalik himself names the limit: “The bigger challenge is for public-key encryption,” and there are long-standing results showing it “cannot be done with hashes alone.” Key exchange needs some structured trapdoor: groups, lattices, codes, or something newer. So for most of us running TLS, SSH, VPNs, and messaging, hash-only is not an option for the part that protects data in transit.

That’s why I won’t bet everything on one family, lattice or anything else. Monoculture is the mistake we made with RSA and ECC, and it’s why this migration is so painful. The hedge is twofold:

1. Hybrids. Combine a post-quantum scheme with a classical one so an attacker has to break both. BSI says this approach “has proven its worth”: a hybrid with a weakened Classic McEliece still gives at least classical security, and ML-KEM, FrodoKEM, and HQC aren’t affected by the new results. HQC matters here because it’s code-based, a different family from the lattice schemes.
2. Swappable crypto. Design so that changing an algorithm is a config change and a rollout, not a rewrite. If lattices take a hit, you want to raise parameters or switch families in weeks.

Migrations are where PQC actually fails

The line from Vitalik’s post I’d put on a poster:

“be careful about migrations; I personally have lost more money in botched migrations than I have lost in all hacks combined.”

Anyone who has run real infrastructure knows exactly what he means. Algorithms rarely fail in production. Operations fail. The certificate nobody knew about expires. A hardcoded cipher list sits in a library three dependencies deep. A rotation script runs for the first time during an incident. A key gets moved and its backup doesn’t.

Deadlines are now real for a lot of us. NSA announced on October 1 that under CNSSP 15, “starting in 2027, all new commercial NSS must be capable of supporting quantum-resistant algorithms,” and legacy systems that can’t are “to be phased out by 2030.” Whatever sector you’re in, the work is the same: know where your crypto lives, make it swappable, and practice the swap until it’s boring.

How-To: crypto-agility you can start this week

Every command below is real and was checked against official docs or release notes. Try them on lab systems first.

1. Inventory: find out what you’re actually negotiating

You can’t migrate what you can’t see. Start with TLS. With OpenSSL 3.5 or later, s_client reports the negotiated key exchange group:

openssl version
echo | openssl s_client -connect example.com:443 -servername example.com -brief 2>&1 \
  | grep "Negotiated TLS1.3 group"

A hybrid endpoint shows Negotiated TLS1.3 group: X25519MLKEM768. To check whether a server supports the hybrid at all, offer only that group with -groups X25519MLKEM768. If the handshake fails, it doesn’t.

For SSH, list the host key types your servers present, and see which key exchange your client actually picks:

ssh-keyscan host.example.com
ssh -v host.example.com exit 2>&1 | grep "kex: algorithm"

Script these across your fleet and write the results down. That list is your migration map.

2. OpenSSH: confirm hybrid key exchange, then test hybrid signatures

Check your version with ssh -V. Since OpenSSH 10.0, the hybrid mlkem768x25519-sha256 is the default key exchange. If you manage KexAlgorithms explicitly, make sure it leads the list. In ssh_config or sshd_config, a leading ^ places your choice at the head of the default set:

KexAlgorithms ^mlkem768x25519-sha256

ssh -Q kex lists what your build supports. Since 10.1 the client warns when a connection negotiates non-post-quantum key agreement, and 10.6 adds the same WarnWeakCrypto logging on the server, on by default. Leave those warnings on. They’re free inventory.

OpenSSH 10.6, released October 6, enables the hybrid ssh-mldsa44-ed25519 signature algorithm (ML-DSA-44 plus Ed25519). Try it somewhere low-stakes:

ssh-keygen -t mldsa44-ed25519 -f ~/.ssh/id_mldsa44_ed25519
ssh -i ~/.ssh/id_mldsa44_ed25519 -o IdentitiesOnly=yes lab-host.example.com

Add the .pub to authorized_keys on a 10.6 lab host first. One gotcha from the release notes: keys made with the earlier experimental support “must be regenerated and/or removed,” because the algorithm name dropped its @openssh.com suffix. That’s a small migration in itself. Treat it as practice.

3. TLS: prefer hybrid groups where you can

OpenSSL 3.5 supports X25519MLKEM768, and on my test box it’s what a 3.5 client negotiated by default against a hybrid-capable server. For nginx built against OpenSSL 3.5 or later, the ssl_ecdh_curve directive sets the groups the server supports, in order:

ssl_protocols TLSv1.3 TLSv1.2;
ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1;

Hybrid first, classical fallback for older clients. Then verify with the s_client check from step 1. Don’t trust the config. Trust the handshake.

4. Keep algorithm choices in config

Swapping algorithms should be a config change, not a code change. Grep your codebase for hardcoded curve names, cipher suites, key sizes, and KexAlgorithms strings. Move them into config that’s version-controlled, reviewed, and deployed like any other change. The ^, +, and - prefixes in OpenSSH and the colon-separated group lists in OpenSSL exist for this reason. If raising a parameter set or dropping a family means a code release in five repos, your agility exists only on paper.

5. Rehearse rotation with short-lived credentials

The best way to make rotation safe is to do it so often it stops being an event. Let’s Encrypt announced on October 7 that starting February 10, 2027, its default certificate lifetime drops to 64 days, with 45-day defaults coming in 2028. Its advice: if your renewals are hard-coded to a date from expiration, “update them to renew at approximately ⅔ of the lifetime instead,” and “grep for common hardcoded numbers like 83, 80 or 60 in cron jobs, wrapper scripts and runbooks.” If your ACME client supports ACME Renewal Info (ARI), the CA can tell it when to renew.

Do that, and extend the idea past web certs. Short-lived SSH certificates instead of long-lived keys. Automated reload and deploy. Alerting on renewal failure. Then run a game day: rotate a key or swap an algorithm on purpose, on a schedule, and see what breaks. Every rotation you rehearse now is one you won’t botch during an incident.

The close

Vitalik is right to take AI-accelerated cryptanalysis seriously, right that hash-based signatures are the conservative choice where they fit, and right that migrations hurt more than hacks. My addition is that none of us knows which assumption breaks next. It could be ECDSA, a lattice parameter set, or a code-based scheme that already survived nearly fifty years, as McEliece just showed.

So don’t bet the house on one family. Run hybrids. Keep algorithms in config. Know where every key lives. Rotate often enough that it’s boring. Math over promises, and operations over hope.

Views are my own and do not represent my employer. Nothing here is financial advice.