Read this first
Nostr public keys are published by design, and secp256k1 falls to a quantum computer. That breaks encrypted DMs retroactively and event signatures prospectively - two problems with very different deadlines. We are proposing a NIP that derives post-quantum keys from the same BIP39 seed a Nostr identity already uses, and publishes them in a replaceable attestation event. It requires no relay changes and no changes from clients that do not opt in.
A Nostr identity is a secp256k1 keypair, and the public half is published to every relay it touches. That is the point - it is how anyone verifies your notes. It is also the exposure: Shor's algorithm recovers a private key from a public key, and Nostr publishes the input.
Two harms follow, and conflating them is the main reason this problem has stayed unsolved.
Two problems, two deadlines
The first is retroactive. NIP-44 derives its conversation key from an ECDH shared secret between two secp256k1 keys. Anyone who archives encrypted events today and breaks secp256k1 in fifteen years can decrypt all of them, at leisure. CISA, the NSA and NIST call this "catch now, break later" in their joint quantum-readiness guidance, and it is the reason early planning is necessary rather than merely prudent.
The critical property is that this damage is already accruing. Every NIP-44 event published today is a future plaintext. Nothing published after the break can retroactively protect a message sent before it.
The second harm is forgery. The same adversary can sign events as you - post notes in your name, rewrite your history. This is worse in impact but better in timing: it is a live-attack problem. It cannot be mitigated by anything published in advance, only by migrating signatures before the break happens.
Which one to solve first
Only confidentiality can be fixed retroactively, so confidentiality is what has to be fixed now. Signature migration is more disruptive and less urgent - and, crucially, it stays possible later only if identities commit to a post-quantum signing key before the break, not after.
Why previous proposals stalled
Post-quantum Nostr is not a new idea. Paul Miller - author of the noble cryptography libraries much of the ecosystem depends on - opened issue #1971 in July 2025 to discuss exactly this, and it has been live ever since, with fiatjaf, Vitor Pamplona and Mike Dilger all weighing in.
The thread keeps arriving at the same objection, and it is a good one. Most proposals derive the post-quantum key from the Nostr private key: pq_key = KDF(nsec). That is circular. An adversary who recovers nsec from npub runs the same KDF and obtains the post-quantum key too. As Miller put it in April, in a design like that the subkeys are derived the moment the identity key falls.
This objection is fatal to the obvious approach, and it is why the thread has produced working prototypes but no NIP.
Siblings, not children
Our proposal derives the secp256k1 key and the post-quantum keys as siblings from a common seed, never one from the other.
NIP-06 already specifies deriving a Nostr key from a BIP39 mnemonic at m/44'/1237'/0'/0/0. That derivation runs through HMAC-SHA512 and is one-way: given the resulting private key, you cannot walk back to the seed. So we take the same 64-byte seed and expand it a second time, with domain separation, into an ML-KEM key and an ML-DSA key.
The consequence is the whole proposal. An adversary who breaks secp256k1 and recovers the Nostr private key learns nothing about the seed, and therefore nothing about the post-quantum private keys. Messages encrypted to the ML-KEM key stay confidential permanently, even after the identity key is gone.
What this does not fix
An adversary with a quantum computer can still forge events, because events are still signed with secp256k1 - including publishing a replacement attestation carrying their own post-quantum keys, and intercepting future messages. This protects past messages permanently. It does not protect future messages against an adversary who has already broken secp256k1. Anyone claiming otherwise is overselling.
Twenty-four words, and why the number matters
BIP39 expands any mnemonic to a 64-byte seed, so a 12-word phrase derives working post-quantum keys. But it carries only 128 bits of actual entropy. Grover's algorithm provides at most a quadratic speedup on unstructured search, so 128 bits is a materially thinner margin than 256 - and at that point the seed, not the lattice, is the weakest link.
So the first concrete change is unglamorous: generate 24-word seed phrases by default. It costs nothing today, it cannot be applied retroactively, and it is the difference between an identity that can carry a full-strength post-quantum key later and one that cannot. We have opened that change against the nostr-wot browser extension.
Existing 12-word identities are not abandoned. They derive post-quantum keys too - strictly better than nothing - but the attestation records the seed strength, so a correspondent can see what they are relying on. Silent downgrade is the failure mode worth engineering against.
Where the key lives
The public key has to be discoverable. The tempting answer is a field in the kind 0 profile, since that content is free-form JSON. It is the wrong answer.
Most clients rebuild the profile object from the fields they know about and republish it. An unknown post-quantum field is dropped the first time the user edits their display name in a client that has not implemented this. The user still believes they are reachable post-quantum; senders stop seeing a key and quietly fall back to classic encryption. A security feature whose failure mode is invisible is worse than no feature.
So the keys go in a dedicated replaceable event, kind 10203, signed by the identity's ordinary key. No other client has a reason to overwrite it, and it carries what kind 0 cannot: algorithm identifiers, seed strength, versioning for rotation. A kind 0 mirror is allowed as a discovery hint, but the dedicated event wins.
Proving you hold the key
A secp256k1 signature over that event proves the identity published those bytes. It does not prove the identity holds the corresponding post-quantum private keys - someone could advertise a key they cannot decrypt with, by bug or by design, and correspondents would send messages nobody can read.
So the ML-DSA key counter-signs the declaration, over a message binding the Nostr pubkey and both post-quantum keys together. ML-KEM cannot sign, so this is also what gives the encryption key its possession proof. The reasoning follows Vitor Pamplona's Key Set Declaration proposal, which makes the same argument about unilateral key claims enabling impersonation.
Hybrid, deliberately
The post-quantum shared secret is never used alone. It is combined with the existing NIP-44 conversation key through a KDF, so the result is no weaker than either input. A flaw in a comparatively young lattice scheme must not be able to make Nostr messaging worse than it is today - and lattice schemes do break: HAWK, a third-round NIST candidate, was broken this July.
This also puts the proposal on a particular side of a live disagreement. Twenty-one European agencies jointly recommend deploying post-quantum cryptography in hybrid form; the NSA says it does not expect to approve or require hybrid solutions, on the grounds that hybrids add a second migration later. For an open protocol with no central authority and no ability to coordinate a flag day, hybrid is the only honest option.
The whole construction rides inside the existing gift wrap machinery. The outer layers stay secp256k1, which means post-quantum messages traverse today's relay network unmodified and clients that have not implemented any of this are unaffected.
Be honest about what this does not do
An adversary with a quantum computer can still sign events as you, because events are still signed with secp256k1. They can also publish a *replacement* attestation carrying their own post-quantum keys and intercept your future messages.
So this protects past messages, permanently. It does not protect future messages against someone who has already broken secp256k1. Any proposal claiming otherwise is overselling, and we would rather say so than let the claim inflate.
It is running, not theoretical
The specification is implemented and live. Open the chat demo: two identities are generated in your browser, publish their `kind:10203` attestations to public relays, read each other's ML-KEM keys back off those relays, and exchange real post-quantum encrypted 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.
The same page will take any event apart layer by layer: the kind:1059 gift wrap a relay actually stores, the kind:13 seal inside it, the post-quantum envelope with its byte map, and the kind:14 rumor at the centre. Layers the browser holds no key for are marked sealed rather than guessed at, so switching between accounts shows the same event from a different vantage, which is the clearest way to see what the encryption is doing.
To check whether an identity is reachable post-quantum, paste an npub into the checker. To get keys of your own, the Nostr WoT extension derives them from your existing seed phrase and publishes the attestation in one click, and the reference implementation is on npm as `@nostr-wot/pq`.
Measured, not estimated
An attestation is 12,200 bytes. A post-quantum direct message is roughly 4,600 bytes on the wire against 1,700 for the classic equivalent: 2.7x, of which 1,568 bytes is the ML-KEM ciphertext itself. One relay in our four-relay set rejects the attestation on size; three accept it, which is enough for discovery. That is a real constraint the specification has to address, and we found it by publishing rather than by estimating.
What we are not proposing yet
Not signature migration. An ML-DSA-87 signature is 4,627 bytes - roughly 6.2 KB once base64-encoded - added to every event on the network. That is a several-fold increase in relay storage and bandwidth for a typical short note, and it is a network-economics decision that needs relay operators at the table, not a client-side change anyone can ship unilaterally.
Publishing the ML-DSA verification key now is what keeps that door open. The commitment exists, signed by the classic key, from before the break - so when signatures do migrate, users do not need a new seed phrase. That is the part that has to be right today, because it is the part that cannot be fixed later.
The point
The deadline that matters is not when quantum computers arrive. It is the point after which the messages being sent now are no longer worth protecting - and for anything sensitive, that date is already behind us. Deriving post-quantum keys from the seed a user already has costs nothing today and is the only version of this migration that does not ask everyone to start over.
References
- NIP-06: Basic key derivation from mnemonic seed phrase (github.com) - the existing BIP39 derivation this proposal extends.
- NIP-44: Versioned encryption (github.com) - the conversation-key construction whose secrets are retroactively exposed.
- NIP-59: Gift Wrap (github.com) - the sealing and wrapping layers the post-quantum payload rides inside.
- Issue #1971: NIP-44 post-quantum security (github.com) - Paul Miller's open discussion, and the source of the derivation objection this proposal answers.
- PR #2424: NIP-A1 Key Set Declaration (github.com) - Vitor Pamplona on why unilateral key declarations enable impersonation.
- FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard (nist.gov) - ML-KEM, final, published 13 August 2024.
- FIPS 204: Module-Lattice-Based Digital Signature Standard (nist.gov) - ML-DSA, final, published 13 August 2024.
- NIST IR 8547 ipd: Transition to Post-Quantum Cryptography Standards (nist.gov) - proposed timelines: ECDSA and ECDH disallowed after 2035. Still an initial public draft, not a final standard.
- Quantum-Readiness: Migration to Post-Quantum Cryptography (cisa.gov) - CISA, NSA and NIST on catch-now-break-later, August 2023.
- Securing Tomorrow, Today: Transitioning to Post-Quantum Cryptography (bsi.bund.de) - twenty-one European agencies recommending hybrid deployment, June 2025.
- Planning for post-quantum cryptography (cyber.gov.au) - Australia's ASD ends approval of ECDH and ECDSA in 2030, the earliest national deadline.
- AI-found flaw sinks HAWK, a NIST PQC candidate - why the hybrid construction is not optional.
- Live post-quantum chat (nostr-wot.com) - two identities registering on public relays and exchanging real ML-KEM encrypted messages, with a layer-by-layer event explorer.
- Post-quantum capability checker (nostr-wot.com) - look up any npub and see whether its attestation validates.
- @nostr-wot/pq (github.com) - the reference implementation: derivation, attestation, proof of possession, and the message envelope.
- Nostr WoT extension (github.com) - derives the keys from an existing seed phrase and publishes the attestation.