199 lines
12 KiB
Markdown
199 lines
12 KiB
Markdown
# 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`](../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](https://github.com/nostr-protocol/nips/blob/master/44.md) 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)
|
|
- **Author**: trbouma
|
|
- **Created**: 2026-01-09 | **Updated**: 2026-03-04
|
|
- **URL**: https://github.com/nostr-protocol/nips/pull/2185
|
|
- **Status**: Open, 7 comments, 1 commit, +113 lines
|
|
|
|
**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)
|
|
- **Author**: eznix86
|
|
- **Created**: 2023-03-24 | **Closed**: 2025-05-22 (not merged)
|
|
- **URL**: https://github.com/nostr-protocol/nips/pull/391
|
|
|
|
**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)
|
|
- **Author**: paulmillr
|
|
- **Created**: 2025-07-10 | **Updated**: 2026-04-13
|
|
- **URL**: https://github.com/nostr-protocol/nips/issues/1971
|
|
- **26 comments** — the most active PQ discussion in the Nostr community
|
|
|
|
**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.
|
|
- Repo: https://github.com/zfatherz/nip44-0xF1-pqc
|
|
|
|
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)
|
|
- **Author**: fiatjaf
|
|
- **Created**: 2024-12-14
|
|
- **URL**: https://github.com/nostr-protocol/nips/pull/1647
|
|
|
|
**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)
|
|
- **Author**: leonacostaok
|
|
- **Created**: 2026-02-24 | **Closed**: 2026-02-26
|
|
- **URL**: https://github.com/nostr-protocol/nips/issues/2237
|
|
|
|
**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.
|