Skip to main content

​
You don’t need a physics degree for this

Post-quantum cryptography sounds intimidating. It’s not. Here’s the whole story in plain language, with enough technical detail for the curious.

​
What quantum computers actually threaten

Today’s public-key cryptography (RSA, ECDSA, ECDH) relies on math problems that classical computers find extremely hard:
  • Factoring large numbers (RSA)
  • Computing discrete logarithms on elliptic curves (ECDSA, ECDH)
In 1994, Peter Shor published an algorithm that solves both of these problems efficiently on a quantum computer. Not faster. Efficiently. The difference between “takes billions of years” and “takes hours.” The catch: nobody has a quantum computer powerful enough to run Shor’s algorithm on real cryptographic keys yet. Current estimates put that at 10-15 years away. But the research is accelerating.

​
Why 10-15 years away matters today

Here’s the scenario that keeps cryptographers up at night: Harvest-now, decrypt-later. An adversary records encrypted data today. They store it. It’s cheap to store data. Then, in 2035 or 2040, when a quantum computer is available, they decrypt everything retroactively. For most encrypted communications, this is a known risk. But for blockchains, it’s worse:
  • Blockchain data is permanent. You can’t delete an announcement from the chain.
  • The data is public. Anyone can collect it. No need to intercept traffic.
  • Privacy systems leave durable cryptographic artifacts. Ciphertexts, ephemeral public keys, identifiers.
If a privacy system uses classical crypto today, all the private payments it handles are potentially vulnerable to future quantum attacks. That’s a betrayal of the privacy promise.

​
How classical stealth addresses work (and break)

Classical stealth systems (ERC-5564 schemeId 1, Umbra) use ECDH (Elliptic Curve Diffie-Hellman): 
Sender:   picks random scalar r, computes R = r*G (ephemeral public key)
          computes shared_secret = r * recipient_public_key
Recipient: computes shared_secret = private_key * R
Both sides arrive at the same shared secret. From it, they derive the stealth address. The problem: R (the ephemeral public key) is stored on-chain in the announcement. A quantum attacker can compute r from R using Shor’s algorithm, then derive the shared secret, then identify the recipient.

​
How ML-KEM works (and doesn’t break)

ML-KEM (Module Lattice-based Key Encapsulation Mechanism) replaces ECDH with math based on lattice problems. Instead of elliptic curves, ML-KEM works with polynomial matrices plus random noise: 
Key generation: Create a secret polynomial vector s
                Public key = A*s + e  (where A is random, e is small noise)

Encapsulation:  Sender uses public key to create:
                - A ciphertext (encrypted shared secret)
                - A shared secret (32 bytes)

Decapsulation:  Recipient uses secret key to recover the shared secret
The security relies on the Module Learning With Errors (MLWE) problem: given the noisy product A*s + e, recovering s is computationally hard. No quantum algorithm solves this efficiently. No classical algorithm does either.

​
Why ML-KEM-768 specifically?

NIST (the US National Institute of Standards and Technology) evaluated dozens of post-quantum proposals over 8 years. In August 2024, they published the final standard: FIPS 203 (ML-KEM). ML-KEM comes in three sizes:
VariantSecurity levelPublic keyCiphertextUse case
ML-KEM-512Category 1 (AES-128)800 B768 BGeneral use
ML-KEM-768Category 3 (AES-192)1,184 B1,088 BLong-term protection
ML-KEM-1024Category 5 (AES-256)1,568 B1,568 BMaximum security
SPECTER uses ML-KEM-768 because on-chain data is permanent. You want more than the minimum security margin when the data you’re protecting will exist for decades. Category 3 provides 128+ bits of quantum security, equivalent to AES-192 against quantum adversaries. Overkill for a chat message that expires tomorrow. Appropriate for blockchain data that lives forever.

​
Other post-quantum approaches (and why not)

AlgorithmTypeWhy SPECTER doesn’t use it
NTRULatticeMore complex security history, less community confidence
Classic McElieceCode-basedPublic keys are ~1 MB. Way too large for on-chain meta-addresses.
SPHINCS+ / SLH-DSAHash-basedSignature scheme, not KEM. SPECTER needs key encapsulation for the shared secret.
FALCONLatticeGood for signatures, but ML-KEM is standardized for encapsulation.
ML-DSA (the signature counterpart to ML-KEM) is relevant for the future spending path. SPECTER’s ERC proposal specifies ML-DSA-65 for stealth key signing when smart accounts support it. See the ERC Proposal.

​
The NIST timeline

DateEvent
2016NIST opens post-quantum standardization competition
201782 submissions received
2020Round 3 finalists announced (including CRYSTALS-Kyber, now ML-KEM)
2022ML-KEM selected for standardization
Aug 2024FIPS 203 (ML-KEM) published as final standard
2024-presentMigration begins across TLS, Signal, Chrome, iMessage
SPECTER is part of this migration wave. The crypto industry is adopting ML-KEM. Blockchain privacy systems should too.

​
What about Ethereum itself?

Ethereum’s consensus uses BLS signatures (not broken by quantum). But user wallets use ECDSA over secp256k1 (broken by quantum). SPECTER’s receiving layer is already post-quantum. The spending layer depends on Ethereum’s wallet model. Two paths forward exist:
  1. ERC-4337 smart accounts - Custom signature verification, could use ML-DSA today
  2. EIP-8141 frame transactions - Native PQ transaction support (draft stage)
Read more in Security Boundaries.

ML-KEM in SPECTER's code

How ML-KEM-768 is actually implemented in the Rust crates.

Security boundaries

What’s PQ-safe today and the path to full coverage.