136 lines
4.6 KiB
Markdown
136 lines
4.6 KiB
Markdown
# 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.
|
|
|
|
## 4. Curve and derivation notes
|
|
|
|
`n_signer` currently models curve metadata from day one:
|
|
|
|
- `secp256k1`
|
|
- `ed25519`
|
|
- `x25519`
|
|
|
|
Not every purpose should be valid on every curve. Enforcement should be explicit in policy/runtime validation.
|
|
|
|
## 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)
|