quoting
naddr1qp…pa4zRead first: https://en.wikipedia.org/wiki/Harvest_now,_decrypt_later
Someone is copying your encrypted messages right now. Not breaking them. Copying them.
That is the whole attack. It does not need a quantum computer today. It needs a hard drive today and a quantum computer eventually. Every NIP-44 message you have ever sent, sitting on relays, publicly retrievable, encrypted with a scheme that will not hold. The people doing this are not waiting for permission and they are not in a hurry.
It has a name, "harvest now decrypt later", and the fact that it has a name should tell you how long people have known.
Why Nostr specifically
Your public key is published to every relay you touch. That is not a flaw, it is the entire design. It is how anyone verifies your notes.
It is also the input to the attack. Shor's algorithm recovers a private key from a public key. Most systems at least make an adversary work to obtain the public key first. Nostr hands it over, to everyone, permanently, by default.
NIP-44 derives its conversation key from an ECDH shared secret between two secp256k1 keys. Recover either private key and you recover the conversation key. Recover the conversation key and you decrypt every message in that conversation, all the way back to the first one.
There is no forward secrecy in that construction to save you. There is no key rotation that helps, because the messages were already captured under the old key. There is nothing you can publish tomorrow that protects what you sent yesterday.
The part I cannot get people to hear
When I raise this, the answer is almost always some version of "quantum computers aren't here yet."
That is not a rebuttal. That is the premise.
The deadline is not when the machine arrives. The deadline is how long your message needs to stay secret, counted backwards from when the machine arrives. If you send something today that would still embarrass you, endanger you, or cost you money in twelve years, and the machine shows up in ten, you already missed it. You missed it at the moment you hit send.
So the question is not "when is Q-day". The question is: what did you say last week that still matters in 2036?
For most people the honest answer is "some of it". Not all of it. Some of it. Which is enough.
And it is not only your judgement that is at stake. Every person who messaged you did so believing the thing on the label. They looked at a lock icon, or a client that said encrypted, and they decided what to tell you based on that. If the encryption does not hold, you did not just lose your own privacy. You lost theirs, on their behalf, without asking them.
That is the part that actually bothers me. My own messages I can be philosophical about. I cannot be philosophical about someone else's.
Why this has stayed unfixed for a year
It is not that nobody noticed. Paul Miller opened the issue in July 2025. fiatjaf, Vitor Pamplona and Mike Dilger have all been in that thread. These are not people who miss things.
It stalled on something real. The obvious fix is to derive a post-quantum key from your Nostr private key:
pq_key = KDF(nsec)That is circular and it buys you nothing. An adversary recovers your nsec from your npub, runs the same KDF, and now has your post-quantum key as well. You added computation and no security.
That objection killed every proposal. Working prototypes existed. A specification did not.
The fix is a change of shape, not of algorithm
Do not derive from the nsec. Derive from the seed.
NIP-06 already takes you from a BIP-39 mnemonic to your Nostr key at
m/44'/1237'/0'/0/0, through HMAC-SHA512, which is one-way. Given the resulting private key you cannot walk back to the seed.So take that same seed and expand it a second time, with domain separation, into post-quantum keys:
kem_seed = HKDF-SHA256(seed, info = "nip-pqc/v1/ml-kem-1024/0", 64)
dsa_seed = HKDF-SHA256(seed, info = "nip-pqc/v1/ml-dsa-87/0", 32)Both keys are children of the seed. Neither is a child of the other. They are siblings.
An adversary who breaks secp256k1 and recovers your Nostr private key learns nothing about the seed, because that would mean inverting HMAC-SHA512. So they learn nothing about your post-quantum keys. Messages encrypted to your ML-KEM key stay confidential permanently, even after your identity key is gone.
And your words never change. The same mnemonic restores your Nostr key and both post-quantum keys. There is no new backup, no re-enrolment, no "generate a fresh identity and rebuild your social graph", which is the migration nobody ever completes.
The rest of the design, briefly
Keys go in a
kind:10203replaceable event, not in your kind:0 profile. Clients rebuild profile JSON from the fields they know about and republish it, so the first time you changed your display name in a client that had not implemented this, your post-quantum key would vanish silently. You would still think you were reachable. Senders would quietly fall back to classic encryption. A security feature that fails silently is worse than one that is not there.The ML-DSA key counter-signs a proof of possession binding your npub to both public keys. A secp256k1 signature proves you published those bytes. It does not prove you hold the matching post-quantum secrets. Without the counter-signature you could advertise a key you cannot decrypt with, by bug or on purpose, and people would send you messages nobody can read.
The post-quantum secret is combined with the existing NIP-44 conversation key through HKDF. Never used alone. Lattice schemes are young and they do break, HAWK fell in July. A flaw in a new scheme must not be able to make Nostr messaging worse than it is today.
Everything rides inside NIP-59 gift wrap, unchanged. The outer layers stay secp256k1, so these messages cross today's relay network with no modifications, and clients that know nothing about any of this are unaffected. No relay changes. No flag day.
It is not a proposal, it is running
I am tired of design documents, so we shipped it.
There is a demo at nostr-wot.com/pqc/chat that generates two identities in your browser, publishes their attestations to damus, nos.lol, primal and snort, reads each other's ML-KEM keys back off those relays, and exchanges real post-quantum gift wraps.
Nothing is simulated. A message only appears once a relay hands it back and it decrypts, and each one names the relay that served it. You can take any event apart layer by layer, the kind:1059 wrap a relay actually stores, the kind:13 seal inside it, the envelope with a byte map, and the kind:14 rumor at the centre. Layers your browser holds no key for are marked sealed rather than guessed at, so you can switch accounts and see the same event from a different vantage.
Publishing it for real also taught us something estimating would not have. One of those four relays rejects the 12,200-byte attestation outright, on size. Three accept it, so discovery still works, but that is a real constraint and it is in the spec now rather than in someone's incident report next year.
The browser extension is released. The library is on npm as
@nostr-wot/pq. New identities default to 24 words, because 12 words carry 128 bits of entropy and that would make your seed the weak link instead of the lattice. That change costs nothing today and cannot be applied retroactively, which is exactly why it has to happen now.What this does not do
An adversary with a quantum computer can still sign events as you. Events are still signed with secp256k1. They could also publish a replacement attestation carrying their own keys and intercept your future messages.
This protects past messages, permanently. It does not protect future messages against someone who has already broken secp256k1.
Signature migration is a separate and harder problem. An ML-DSA-87 signature is 4,627 bytes, roughly 6.2 KB base64, on every event. That is a several-fold increase in relay storage and bandwidth for a short note, and it is a decision that needs relay operators at the table, not something a client ships unilaterally.
Publishing the ML-DSA verification key now is what keeps that door open. The commitment exists, signed by your classic key, from before the break. So when signatures eventually migrate, nobody needs a new seed phrase.
I would rather say all of that plainly than let the claim inflate. If someone tells you their post-quantum scheme fixes everything, they have not understood which half of the problem is fixable after the fact.
What to do
If you hold 24 words, you can be post-quantum today. One button in the Nostr WoT extension derives the keys and publishes the attestation. Nothing new to back up.
If you hold a bare nsec, the spec covers you too, with standalone keys marked
origin: independent. They need their own backup, which is worse than derived keys and enormously better than nothing.If you are building a client, the reference implementation is open and the NIP is drafted. Take it apart. Tell me what is wrong with it. I would much rather be corrected now than have this be right and ignored.
And if you do nothing else: stop treating this as a 2035 problem. The messages that will be read are the ones being sent this week.
Written by the Nostr WoT and QuantaKrypto teams. Demo: nostr-wot.com/pqc/chat
Check whether someone supports it: nostr-wot.com/pqc Full write-up: quantakrypto.com/blog/post-quantum-identity-keys-for-nostr
