lfg2025/archy
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases 44 Wiki Activity
archy/docs/adr/008-dual-key-strategy.md
Dorian f149586559 docs: finalize ADRs with 4 new records (FINALDOC-03) 
ADR-006: Nostr relays for decentralized marketplace discovery
ADR-007: DID-based bilateral federation trust
ADR-008: Dual key strategy (Ed25519 + secp256k1)
ADR-009: Manifest-level container security enforcement

Total: 9 ADRs covering all significant architectural decisions.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-03-11 17:23:40 +00:00

2.2 KiB
Raw Blame History

ADR-008: Dual Key Strategy (Ed25519 + Secp256k1)

Status

Accepted

Context

Archipelago operates at the intersection of two cryptographic ecosystems:

  • Web5 / DIDs: The W3C DID specification and Verifiable Credentials ecosystem predominantly uses Ed25519 (EdDSA) for digital signatures
  • Nostr / Bitcoin: The Nostr protocol and Bitcoin ecosystem use secp256k1 (ECDSA/Schnorr) for signatures

A single key type cannot serve both ecosystems without conversion layers or compatibility issues.

Decision

Maintain two key pairs per node identity:

  1. Ed25519 — Primary identity key for DID documents, verifiable credentials, federation authentication, and backup encryption
  2. Secp256k1 — Nostr-compatible key for relay publishing, node discovery, and Lightning Network interactions

Key Derivation

  • Both keys are derived from the same master seed during node initialization
  • The Ed25519 key is the canonical identity (stored in the DID document)
  • The secp256k1 key is linked to the DID via the Nostr profile (NIP-05 verification)

Usage Matrix

Operation Key Used
DID document signing Ed25519
Verifiable credentials Ed25519
Federation auth Ed25519
Backup encryption Ed25519 (via X25519 DH)
Nostr event publishing secp256k1
Node discovery secp256k1 (Nostr)
Lightning channel auth secp256k1

Consequences

Positive

  • Full compatibility with both Web5 and Nostr ecosystems
  • No conversion layers or compatibility hacks needed
  • Each key type is used in its native context (maximum security)
  • Both keys from same seed — single backup protects both
  • Future-proof: can add new key types without breaking existing ones

Negative

  • Two keys to manage instead of one
  • Users need to understand which pubkey is which (mitigated by UI)
  • Key rotation must update both key types
  • Slightly larger DID documents (two verification methods)

Mitigations

  • UI presents a unified identity view — users see "My Identity" not "My Ed25519 Key"
  • Backup system captures the master seed, from which both keys derive
  • DID document includes both verification methods with clear purpose labels