laantungir/n_signer
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 40 Wiki Activity
Files
8015742e29b358f34305cded1a37a8cd0ec531a4
n_signer/plans/seed_phrase_uses.md

7.5 KiB
Raw Blame History

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 §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 §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 §16.1 for the PQ threat model.
  • Verbs: kem_encapsulate, kem_decapsulate (see 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 §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 §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