30 lines
2.5 KiB
Markdown
30 lines
2.5 KiB
Markdown
# Laan's explanation
|
|
|
|
> **⚠️ Research prototype.** This is a short summary of an experimental pre-quantum key-commitment
|
|
> system. It does not, by itself, make a Nostr identity post-quantum secure.
|
|
|
|
A short summary of how the post-quantum Nostr migration works, matching the implementation.
|
|
|
|
1. **Create a new seed phrase.** This is your post-quantum (PQ) Nostr backup. It's a BIP39 mnemonic (24 words by default; 12 words available for testing) — pure entropy, not tied to any algorithm.
|
|
|
|
2. **Derive 5 PQ keypairs from the seed.** Using BIP32 hierarchical deterministic derivation (the same standard as NIP-06), each PQ algorithm gets its own child key under the path `m/44'/1237'/0'/0/`:
|
|
- child 1 → ML-DSA-44
|
|
- child 2 → ML-DSA-65
|
|
- children 3+4 → SLH-DSA-128s
|
|
- children 5+6 → Falcon-512
|
|
- children 7+8 → ML-KEM-768
|
|
|
|
The same seed always produces the same PQ keys, so they're recoverable from the seed phrase.
|
|
|
|
3. **Construct the attestation statement.** A human-readable text statement is created that names your current npub and the Bitcoin block height, and lists the 5 PQ algorithms. This is the `content` of a kind 1 Nostr event.
|
|
|
|
4. **Each PQ key signs the attestation.** Each PQ signature scheme (ML-DSA-44, ML-DSA-65, SLH-DSA-128s, Falcon-512) signs the attestation text. ML-KEM-768 does NOT sign — it's a KEM (Key Encapsulation Mechanism), not a signature scheme. Its public key is included in a tag without a signature.
|
|
|
|
5. **Your existing identity signs the events.** The kind 1 announcement (with PQ signatures in its tags) and a kind 9999 proof carrier (which embeds the kind 1 event as JSON and carries the OpenTimestamps proof) are both signed by your **existing** Nostr identity via `window.nostr.signEvent()`. This authorizes the migration.
|
|
|
|
6. **Timestamp the kind 1 event.** The SHA-256 of the full signed kind 1 event JSON is submitted to OpenTimestamps, anchoring it to the Bitcoin blockchain. This proves the event existed at this point in time, pre-quantum.
|
|
|
|
7. **Publish both events to relays.** The kind 1 announcement and the kind 9999 proof carrier are published. The client then polls for Bitcoin confirmation and republishes the kind 9999 proof carrier with the confirmed OTS proof.
|
|
|
|
**Note:** The seed-derived secp256k1 key (at `m/44'/1237'/0'/0/0`) is derived but not used to sign. There is no "successor signature." The security model relies on OTS precedence — the real event is anchored pre-quantum, and a forged event cannot be backdated to before that anchor.
|