laantungir/nostr_quantum_preparation
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
Files
cfa0ecc2200887fcada9176481a1083af55e3006
nostr_quantum_preparation/research/existing_pq_proposals.md
T

12 KiB
Raw Blame History

Existing Post-Quantum Proposals in the Nostr Ecosystem

⚠️ Research document. A survey of community discussion; not an implementation spec.

A survey of pull requests and issues in nostr-protocol/nips related to post-quantum cryptography, key migration, and key rotation — and how they compare to our plan in README.md.

Research date: 2026-07-12

Summary

There is no merged NIP for post-quantum security. The only merged reference is an acknowledgment in NIP-44 that it has "No post-quantum security." However, there are several open proposals and active community discussions that overlap significantly with our plan. The community is clearly thinking about this but has not converged on a solution.

Directly Post-Quantum Proposals

1. PR #2185: "Add NIP for PQ" (OPEN)

What it proposes:

  • Extends NIP-01 to allow events signed with ML-DSA-44 (FIPS 204) instead of secp256k1 Schnorr
  • Relaxes the pubkey and sig field length constraints in the NIP-01 event format
  • PQ pubkey: 2624 hex chars (1312 bytes); PQ sig: 4840 hex chars (2420 bytes)
  • Detection: if pubkey length > 64 hex chars, use ML-DSA-44 verification
  • Includes a Python proof-of-concept using monstr + oqs (Open Quantum Safe)
  • Author also has a working PQ relay: https://github.com/trbouma/pqrelay

What it does NOT address:

  • No migration strategy for existing users
  • No key linking between old secp256k1 identity and new PQ identity
  • No encryption (NIP-44/NIP-04) PQ upgrade
  • No OpenTimestamps anchoring
  • No seed phrase / root of trust
  • Picks a single algorithm (ML-DSA-44), no multi-scheme hedging

Community comments:

  • vitorpamplona: "We will need to address NIP-44 encryptions with these new keys"
  • kehiy: "Are PQ algos developed enough so we can choose one easily? Maybe we need to wait more"
  • trbouma: "The immediate thing is that it gives nostr a post-quantum narrative to fight the FUD"

Comparison to our plan: This is the simplest possible approach — just swap the signature algorithm. Our plan is significantly more comprehensive: it addresses migration, key linking, encryption, timestamping, and algorithm uncertainty. PR #2185 could be seen as a subset of our Component 3 (PQ signatures) but without the migration scaffolding.

2. PR #391: "NIP-101 Algorithm Transition for Signatures and Encryption" (CLOSED)

What it proposes:

  • A generic algorithm transition event (kind: 101) containing:
    • old_pubkey, new_pubkey, old_alg, new_alg
    • old_signature (signed with old key/algorithm)
    • new_signature (signed with new key/algorithm)
  • Cross-signed transition: both old and new keys sign the transition statement
  • Metadata update via kind: 0 with ["alg", "<algorithm>", "<new_pubkey>"] tag
  • Clients support both old and new during transition period

What it does NOT address:

  • No OpenTimestamps / pre-quantum anchoring
  • No encryption-specific PQ migration (mentions NIP-04 but doesn't detail PQ KEM)
  • No seed phrase root of trust
  • No multi-scheme hedging
  • No storage encryption

Comparison to our plan: This is conceptually similar to our Component 2 (Multi-Scheme Cross-Signed Key-Link Events). The cross-signing concept is the same — old key signs new key and vice versa. However, our plan improves on this significantly:

  • We use OpenTimestamps to anchor the link pre-quantum (prevents backdated fraudulent links)
  • We support multiple PQ schemes simultaneously (no algorithm consensus needed)
  • We derive keys from a seed phrase rather than generating new random keys
  • We include ML-KEM for encryption, not just signatures

3. Issue #1971: "NIP-44: post-quantum security" (OPEN — most active discussion)

Key discussion points:

  1. paulmillr's framing: The main question is not which algorithm, but how new algorithms interop with old infrastructure. Suggests hybrid ECDH + KEM approach (like Apple iMessage, Signal, WhatsApp, OpenSSH).

  2. The "whole architecture" problem: paulmillr identifies the core dilemma — if secp256k1 is broken, everything breaks (signing, identity), so fixing only NIP-44 encryption is insufficient. An attacker who breaks nsec can derive any subkeys.

  3. mikedilger: The real threat is collect-now-decrypt-later for encrypted data on public relays. Favors SPHINCS+ (SLH-DSA) as most conservative. Advocates decoupling encryption from identity (PR #1647).

  4. trbouma: NIP-44 is already quantum-safe if you use a separate key not derived from nsec. The key management is the hard part. Suggests HSM/enclave for PQ keys.

  5. vitorpamplona: If nsec is broken, PQ shared keys derived from it are also broken. "Looks like we will have 2 Nostr's going" — doesn't think PQ signing can be backward compatible.

  6. paulmillr's proposal: Add a pqsig field to NIP-01 events. Old key signs new PQ key and vice versa. Need key rotation mechanism.

  7. zfatherz: Built a working PoC — version byte 0xF1, ML-KEM-768 + X25519 hybrid KEM, XChaCha20-Poly1305 AEAD. ~15-22ms encrypt, ~1145B overhead per packet. Identified O(N) scaling problem for group chats. Later pivoted to O(1) sender-key approach.

  8. alex-s168: SPHINCS+ has small public keys (64 bytes) but 30KB signatures. Mentions Sphinx-in-the-Head for group signatures (but multi-MB signatures).

  9. paulmillr's final critique (2026-04-13): Points out that in zfatherz's design, npub is still derived from nsec, so breaking nsec breaks everything including derived subkeys.

Comparison to our plan: This discussion validates several core elements of our plan:

  • The collect-now-decrypt-later threat is exactly what our OTS anchoring (Component 3) and PQ encryption (Component 5) address
  • The "whole architecture" problem paulmillr identifies is what our key-link events (Component 2) solve — we don't just fix encryption, we migrate identity
  • The algorithm uncertainty concern is addressed by our multi-scheme approach
  • The key derivation from nsec weakness paulmillr identifies is why our plan uses a seed phrase (Component 1) as the root of trust, not nsec-derived keys
  • zfatherz's PoC validates that hybrid ML-KEM + ECDH is practical for 1:1 messaging today

Key Migration / Rotation Proposals (Not PQ-Specific but Relevant)

4. PR #1647: "nip4e: Decoupling encryption from identity" (OPEN)

What it proposes:

  • Per-device encryption keys separate from identity key
  • kind: 10044 — announce encryption public key
  • kind: 4454 — announce a new device's local key
  • kind: 4455 — share encryption secret to a new device (NIP-44 encrypted)
  • Solves: FROST/MuSig2 bunkers where identity key isn't available for encryption, offline encryption, per-device performance

Comparison to our plan: This is not PQ-specific but is foundational infrastructure. Our plan's Component 5 (Quantum-Safe Self-Storage) and the encryption migration could build on this pattern. The concept of separating encryption keys from identity keys is shared. mikedilger explicitly referenced this PR in the #1971 discussion as a prerequisite for PQ encryption.

5. Issue #2237: "Key Commitment and Theft-Proof Rotation" (CLOSED)

What it proposes:

  • Argon2id-based hash commitment scheme for key rotation
  • kind: 13375 — publish commitment (argon2id of a secret passphrase with pubkey as salt)
  • kind: 13376 — rotation event from new key revealing the secret
  • Clients verify: argon2id(revealed_secret, old_pubkey) == commitment
  • Aims to prove theft vs. voluntary migration

Comparison to our plan: Different approach to the rotation problem. Uses a memory-hard KDF commitment rather than cross-signing. Does not address PQ specifically. Our plan's cross-signed key-link events are more cryptographically rigorous (actual signatures, not passphrase commitments) and include OTS anchoring to prevent backdating.

6. Other Key Migration PRs (OPEN, not reviewed in detail)

  • PR #2114: NIP D8 Key Rotation
  • PR #2137: Key migration
  • PR #2139: Simpler key migration
  • PR #1452: Key Migration and Revocation
  • PR #829: NIP-41: simple account migration
  • PR #2361: Decoupling identity and encryption keys in NIP-17
  • PR #637: NIP-37: general methods for dealing with lost keys

These are all related to key migration/rotation but are not PQ-specific. Our plan's key-link event (Component 2) is in the same category but specifically designed for PQ migration with OTS anchoring and multi-scheme support.

Gap Analysis: What Our Plan Uniquely Addresses

Feature PR #2185 PR #391 Issue #1971 PR #1647 Our Plan
PQ signatures ✅ (ML-DSA-44 only) ✅ (generic) Discussed ❌ ✅ (multi-scheme)
PQ encryption (KEM) ❌ Mentioned ✅ (hybrid KEM) ❌ ✅ (ML-KEM + OTP)
Key linking / migration ❌ ✅ (cross-signed) Discussed ❌ ✅ (cross-signed + OTS)
Pre-quantum timestamping ❌ ❌ ❌ ❌ ✅ (NIP-03 OTS)
Seed phrase root of trust ❌ ❌ ❌ ❌ ✅ (BIP39/NIP-06)
Multi-scheme hedging ❌ ❌ ❌ (discussed) ❌ ✅
Existing nsec migration ❌ ❌ ❌ ❌ ✅
Storage encryption ❌ ❌ Discussed Partial ✅ (OTP / symmetric)
HD wallet compartmentalization ❌ ❌ ❌ ❌ ✅
Decouple encryption from identity ❌ ❌ Discussed ✅ ✅ (via seed derivation)

Key differentiators of our plan:

  1. OpenTimestamps anchoring — no other proposal addresses the backdating attack on key-link events
  2. Multi-scheme hedging — no other proposal links to multiple PQ algorithms simultaneously
  3. Seed phrase as root of trust — no other proposal uses BIP39 as the algorithm-agnostic foundation
  4. Existing nsec migration — no other proposal addresses how raw nsec users migrate
  5. HD wallet compartmentalization — no other proposal leverages BIP32 chain codes for quantum containment

Recommendations

  1. Engage with PR #2185: trbouma's PR is the most active PQ proposal. Our plan is a superset — we should comment with our more comprehensive approach, particularly the migration strategy and OTS anchoring that their PR lacks.

  2. Engage with Issue #1971: This is the main community discussion. paulmillr's final critique (npub derived from nsec → everything breaks) is directly addressed by our seed-phrase approach. We should contribute our key-link + OTS design.

  3. Reference PR #1647: fiatjaf's encryption/identity decoupling is complementary. Our plan could adopt the kind: 10044 pattern for announcing PQ encryption keys.

  4. Reference PR #391: eznix86's cross-signed transition event is conceptually similar to our key-link event. We should acknowledge this prior art and explain how our approach extends it (OTS, multi-scheme, seed-based).

  5. Watch zfatherz's work: The 0xF1 hybrid KEM PoC is the most advanced PQ encryption implementation. Our plan's encryption component should be compatible with this approach.

  6. Our plan fills a unique niche: No existing proposal combines migration strategy + OTS anchoring + multi-scheme hedging + seed phrase root of trust. This is a strong differentiator for a NIP submission.

Reference in New Issue View Git Blame Copy Permalink