n_signer/plans/seed_phrase_uses.md

# Seed Phrase Use Catalog for n_signer

This document catalogs potential uses of a single memorized BIP-39 seed phrase when mediated through `n_signer` role/purpose/curve controls.

It is intentionally expansive: some entries are immediate, others are future-facing.

## 1. Core idea

A single mnemonic can deterministically derive many key families. `n_signer` treats those as distinct role entries with explicit metadata:

- purpose
- curve
- derivation selector/path
- policy scope

This prevents "same seed means same trust domain" mistakes by separating identities at the policy layer.

## 2. Immediate and near-term domains

### 2.1 Nostr identities (`purpose="nostr"`)

- Curve: `secp256k1`
- Typical shorthand: `nostr_index` -> `m/44'/1237'/<index>'/0/0`
- Uses:
  - main pub identity
  - throwaway anti-correlation identity
  - per-app/per-origin identities
  - delegated service identities for local systems

### 2.2 Bitcoin keys (`purpose="bitcoin"`)

- Curve: `secp256k1`
- Typical path families (examples):
  - BIP44 legacy account trees
  - BIP49 wrapped-segwit
  - BIP84 native segwit
  - BIP86 taproot keypath flows
- Uses:
  - deterministic receive/change branches
  - per-context account segregation
  - deterministic recovery for wallet setups

### 2.3 Lightning-related identity material

- Curve: usually `secp256k1`
- Uses vary by node software and key hierarchy model.
- Practical use with `n_signer` should be constrained to explicit purpose-bound role entries, not shared with general signing identities.

### 2.4 Mesh/service identities (`purpose="fips"` and similar)

- Curve: primarily `secp256k1` in current planning
- Uses:
  - deterministic node identity roots
  - stable key-derived addressing inputs
  - service bootstrapping in reproducible deployments

## 3. Additional potential domains

### 3.1 SSH identity material (`purpose="ssh"`)

- Candidate curves: `ed25519` (primary), potentially others
- Uses:
  - deterministic host/user key regeneration
  - environment-specific SSH key derivation without storing private keys on disk

### 3.2 age-style encryption identities (`purpose="age"`)

- Candidate curves: `x25519` / age-native identity mapping
- Uses:
  - deterministic file encryption identity recovery
  - reproducible offline decryption setups

### 3.3 WireGuard-like transport identities

- Candidate curves: curve25519 family
- Uses:
  - deterministic tunnel identity generation
  - ephemeral/per-peer derivation schemes (policy-gated)

### 3.4 PGP/OpenPGP-like profiles (future)

- Possible but operationally complex due to multipurpose key lifecycles and tooling expectations.
- Better treated as explicit, isolated purpose entries if ever added.

### 3.5 Deterministic password or secret derivation (future)

- Could derive app/site secrets from role-scoped KDF outputs.
- Must never blur boundaries with signing keys; separate purpose namespace and strict export policy required.

### 3.6 API/service auth tokens (future)

- Per-service deterministic auth keys (HMAC or asymmetric challenge keys depending on service model).
- Strongly policy-scoped to avoid accidental cross-service linkage.

### 3.7 Post-quantum signature identities (`purpose="pq-sig"`)

- Candidate curves: `ml-dsa-65`, `slh-dsa-128s`
- Derivation paths:
  - ML-DSA-65: `m/44'/102003'/<n>'/0'/0'` → seed → SHAKE-256 DRBG → PQClean keygen
  - SLH-DSA-128s: `m/44'/102004'/<n>'/0'/0'` → seed → SHAKE-256 DRBG → PQClean keygen
- Uses:
  - PQ-aware protocol signatures
  - future SSH PQ signing keys (when OpenSSH adds support)
  - general-purpose PQ signatures for forward-looking applications
- Note: OpenSSH does not yet support PQ signing keys. These are forward-looking — the primitives are ready for when the ecosystem adopts them. See [`plans/post_quantum_crypto.md`](post_quantum_crypto.md) §2.3 for the SSH PQ landscape.
- Note: SLH-DSA-128s signing on ESP32 can take 5–30 seconds. Choose per-role whether the latency tradeoff is acceptable.
- Verbs: `sign_data`, `verify_signature` (see [`README.md`](../README.md) §5).

### 3.8 Post-quantum key encapsulation (`purpose="pq-kem"`)

- Candidate curves: `ml-kem-768`
- Derivation path: `m/44'/102005'/<n>'/0'/0'` → seed → SHAKE-256 DRBG → PQClean keygen
- Uses:
  - PQ key agreement for encryption (encapsulate a shared secret against a peer's ML-KEM-768 public key)
  - hybrid PQ+classical key exchange (client combines ML-KEM-768 with x25519)
  - future PQ TLS session key establishment
- Note: ML-KEM-768 addresses the harvest-now-decrypt-later threat for key agreement. See [`documents/SECURITY.md`](../documents/SECURITY.md) §16.1 for the PQ threat model.
- Verbs: `kem_encapsulate`, `kem_decapsulate` (see [`README.md`](../README.md) §5).

## 4. Curve and derivation notes

`n_signer` models these curves:

- `secp256k1` — Nostr, Bitcoin
- `ed25519` — SSH signatures
- `x25519` — key agreement (age)
- `ml-dsa-65` — PQ signatures (FIPS 204)
- `slh-dsa-128s` — PQ hash-based signatures (FIPS 205)
- `ml-kem-768` — PQ key encapsulation (FIPS 203)

Derivation paths use BIP-44 structure with distinct coin types per algorithm family:

| Algorithm | Coin type | Path | Derivation style |
|---|---|---|---|
| secp256k1 (nostr) | 1237 | `m/44'/1237'/<n>'/0/0` | BIP-32 (NIP-06) |
| secp256k1 (bitcoin) | 0 | `m/44'/0'/<account>'/0/0` etc. | BIP-44 |
| ed25519 (ssh) | 102001 | `m/44'/102001'/<n>'/0'/0'` | SLIP-0010 (all hardened) |
| x25519 (age) | 102002 | `m/44'/102002'/<n>'/0'/0'` | SLIP-0010 (all hardened) |
| ML-DSA-65 (pq-sig) | 102003 | `m/44'/102003'/<n>'/0'/0'` | SLIP-0010 → seed → DRBG → PQClean keygen |
| SLH-DSA-128s (pq-sig) | 102004 | `m/44'/102004'/<n>'/0'/0'` | SLIP-0010 → seed → DRBG → PQClean keygen |
| ML-KEM-768 (pq-kem) | 102005 | `m/44'/102005'/<n>'/0'/0'` | SLIP-0010 → seed → DRBG → PQClean keygen |

The 102XXX coin type range is unregistered in SLIP-44 and chosen to avoid collisions with real cryptocurrencies. All non-secp256k1 paths are fully hardened per SLIP-0010. PQ keys use a seed→DRBG→PQClean keygen approach because PQ private keys are not scalars — see [`documents/SECURITY.md`](../documents/SECURITY.md) §16.2 for the security argument.

Not every purpose should be valid on every curve. Enforcement is explicit in the `(verb, purpose, curve)` matrix — see [`README.md`](../README.md) §6.

## 5. Operational caveats

1. **One seed phrase is one root compromise domain**
   - If the mnemonic is exposed, every derivable domain is exposed.

2. **Purpose isolation is mandatory**
   - Reusing one role across unrelated domains collapses privacy and security boundaries.

3. **Pre-registration requirement matters**
   - Arbitrary ad-hoc `role_path` requests are too permissive; only pre-registered paths should be derivable by clients.

4. **Policy must constrain verbs + purposes + roles**
   - A caller authorized for Nostr signing should not implicitly gain rights for Bitcoin or SSH derivations.

5. **Auditability and naming discipline are crucial**
   - Human-readable role names should clearly encode domain intent to avoid operator mistakes.

## 6. Practical guidance

Recommended baseline for early deployments:

- keep `purpose="nostr"` roles as primary production scope
- add non-Nostr purposes only when a concrete consumer exists
- require explicit approval to register new purpose+path combinations
- test recovery procedures per purpose before relying on them operationally

## 7. Relationship to main docs

- Product behavior contract: [`README.md`](../README.md)
- Implementation sequencing: [`plans/nsigner.md`](nsigner.md)
- Browser integration planning: [`plans/nsigner_browser_extension.md`](nsigner_browser_extension.md)