No description
- Rust 100%
| docs | ||
| seedkeep_core | ||
| seedkeep_tui | ||
| zeroth | ||
| .gitignore | ||
| AGENTS.md | ||
| Cargo.lock | ||
| Cargo.toml | ||
| README.md | ||
SeedKeeper
Offline-first, single-device encrypted vault for cryptographic seeds (BIP39, Polyseed, Monero). v1 is an encrypted storage library with a TUI on top — no network, no signing, no blockchain logic.
Status: early. Encryption envelope is specified (
spec_final.md) and being implemented; the core types are plaintext scaffolding for now.
Workspace
| Crate | Role |
|---|---|
seedkeep_core |
Keep/Seed types, Envelope (encrypt/decrypt), storage I/O |
seedkeep_tui |
Presentation only — thin UI over seedkeep_core; no crypto |
zeroth |
Low-level crypto primitives: Argon2id, XChaCha20-Poly1305, BLAKE3 |
wally |
Seed-format helpers and wordlists; validation deferred |
Rule of thumb: all cryptography and disk I/O live in seedkeep_core (via
zeroth). The TUI never touches crypto directly.
Design at a glance
- One file per keep (
.seedkeep), a self-contained encrypted envelope. - Each keep has its own random 32-byte master key; the whole
Keep(metadata included) is AEAD-sealed under it. - The master key is wrapped by a KEK derived from the password via Argon2id. The envelope stores a list of wraps, so future device-key / recovery unlocks are a non-breaking addition (v1 ships one password wrap).
- AEAD: XChaCha20-Poly1305. KDF: Argon2id (64 MiB, t=3). Hash: BLAKE3.
- All secret material in memory is held in
zeroizetypes.
Threat model (v1)
Defends against: stolen device/backup + offline brute force, and tampering. Does not defend against a live malicious host or memory extraction — that's a hardware concern (Phase 4).
Build & run
cargo build
cargo run -p seedkeep_tui
cargo test
Roadmap
- Phase 1 (current): encrypted storage, password unlock, TUI, import/export.
- Phase 2: cloud backup of encrypted envelopes (dumb blob store, no server crypto), QR airgap transport.
- Phase 3: signing layer (isolated), device identity, device-key wraps.
- Phase 4: threshold recovery, hardware-backed keys.
Docs
spec_final.md— the buildable v1 specification (authoritative).agents.md— operational guidance for contributors / coding agents.spec_v1.md,spec_v2.md,spec_v3.md— earlier drafts, superseded.