Loading…
Loading…
A proposed NIP that lets a Nostr identity derive post-quantum keys from the seed phrase it already has, so encrypted messages sent today stay private after secp256k1 falls. Developed jointly with nostr-wot.
Updated Aug 9, 2026
Read this first
Nostr publishes every public key by design, so a quantum computer breaks encrypted DMs retroactively and event signatures prospectively. Only the first can be pre-empted. We proposed a way to derive post-quantum keys from the existing NIP-06 seed, publish them in a replaceable attestation, and carry post-quantum payloads inside today's gift wrap - with no relay changes and no changes required of clients that do not opt in.
Nostr identities are secp256k1 keypairs whose public half is published to every relay they touch. That is what makes the protocol work, and it is also the exposure: Shor's algorithm recovers a private key from a public key, and Nostr supplies the input.
Post-quantum Nostr was not a new idea. Issue #1971, opened in July 2025 by the author of the noble cryptography libraries, ran for a year with the protocol's most active contributors in it. It produced working prototypes but no specification, and always for the same reason.
Every proposal derived the post-quantum key from the Nostr private key. That is circular: an adversary who recovers the private key from the published public key runs the same derivation and obtains the post-quantum key too. The work added computation and no security.
Our proposal derives the secp256k1 key and the post-quantum keys as siblings from the same BIP-39 seed, never one from the other. NIP-06 already derives the Nostr key from a mnemonic through HMAC-SHA512, which is one-way, so recovering the Nostr private key gives no path back to the seed and therefore none to the post-quantum keys. Messages encrypted to them stay confidential permanently.
The user's twenty-four words are unchanged. That property is the point: it means the migration does not ask anyone to start over, which is the difference between a transition that happens and one that does not.
What the proposal does not claim
It does not stop event forgery. An adversary with a quantum computer can still sign events as any user, and can publish a replacement attestation carrying their own keys to intercept future messages. The proposal protects past messages permanently and says so in its own section - overstating it would be the fastest way to lose a technical audience.
The specification covers only the identity layer: how post-quantum keys come into existence and how a sender finds them. It defines no encryption payload format, no signature format, and no change to event validation, because other contributors already have work in flight on those. A proposal that redefined everything would collide with three efforts at once; one that fills the acknowledged gap and composes with them has a chance.
It also required a decision on parameter sets. We specified ML-KEM-1024 and ML-DSA-87 rather than the smaller Category 3 sets: NSA CNSA 2.0 mandates the larger parameters, and Australia's Information Security Manual withdraws approval for ML-KEM-768 and ML-DSA-65 after 2030. Specifying the smaller sets would have standardised parameters already scheduled for withdrawal, to save roughly 640 bytes per message.
The specification carries test vectors derived from NIP-06's own published mnemonic, asserted against NIP-06's published secp256k1 key, so the seed handling can be checked rather than taken on trust. The reference implementation reproduces those vectors through a different HKDF code path than the one that generated them, which cross-validates both.
The point
Retroactive decryption is the only harm that has to be prevented before the break rather than after it. Deriving post-quantum keys from a seed users already hold costs nothing today and is the only version of this migration that does not ask an entire network to generate new identities.
Each item links to the upstream artefact where one exists. Drafts are listed without a link because they have not been submitted yet.
Specification for deriving ML-KEM-1024 and ML-DSA-87 keys from a NIP-06 mnemonic and publishing them in a replaceable kind:10203 attestation with a proof of possession.
Raises new identities from 128 to 256 bits of seed entropy, the precondition for a full-strength post-quantum key. Cannot be applied retroactively, so it is the first thing worth changing.
Reference implementation of the derivation and the proof-of-possession construction, plus an offline key-generation command and an in-extension panel.
A public tool that looks up an identity's attestation, validates key lengths against FIPS 203 and 204, and verifies the proof of possession in the browser.
The same reasoning we take upstream is what we apply to client systems.