Social Recovery
Shamir social recovery
Split a backup key across trusted guardians with Shamir’s Secret Sharing, then reconstruct a quorum to recover. No servers, no network.
Last updated Jul 2026
Shared Backup · split your Master Key
Overview
A proof-of-concept Shamir Secret Sharing layer for backup and inheritance on Passport. It splits a master seed into N shards with a T-of-N recovery threshold, distributes them to trusted guardians (keycard / NFC / QR), and reconstructs the seed from any quorum, with no network calls and nothing written outside the app.
It composes existing KeyOS primitives (bc-shamir, the Magic Backups shard format and restore pipeline) rather than inventing new crypto, so it integrates into KeyOS 1.3.0 with zero upstream API changes. The cryptographic core (social-recovery-core) is production-grade and covered by 11 unit tests; the Slint UI is a navigable scaffold covering every MVP flow.
What it does
- Parametric Shamir split/reconstruct over bc-shamir, the same crate KeyOS uses for Magic Backups.
- Tests cover 3-of-5 roundtrips, every threshold subset, below-threshold rejection, and cross-set contamination.
- BackupKey derivation pinned to the canonical SHA256(seed ‖ "backup_encryption") used by KeyOS backup.
- Shards reuse the existing backup-shard format (device_id, timestamp, scheme): multi-set support is free.
- Trustee flow: ingest a guardian’s shard, validate set membership, and reject Magic-Backup shards.
- No network I/O, no server calls, no persistence outside the app directory.
- Heir recovery reconstructs the seed locally and bridges into the existing Magic Backups restore.
Technical breakdown
How the app is built, for developers evaluating the platform.
The core crypto crate
social-recovery-core wraps bc-shamir’s split_secret/recover with validated parameters (N 2–255, T 2–N) and returns Magic-Backup-format shards. derive_backup_key() pins to SHA256(seed ‖ "backup_encryption"), bit-for-bit matching KeyOS os/backup. Its unit tests prove roundtrips, every threshold subset, below-threshold rejection, cross-set contamination detection, and key-derivation stability.
No trust in servers
The master seed is read only from device security state. Shards export to keycard / NFC / QR and are reconstructed locally; verification runs in-process without changing device state. There is no server-side set registry: each shard embeds enough metadata (device_id, timestamp) to group its set, and no network is ever touched.
KeyOS integration
Target is KeyOS 1.3.0. The core crate drops into os/gui-app-social-recovery/ (or apps/gui-app-social-recovery/ as a first-party catalog app) unchanged; the UI crate mirrors os/gui-app-launcher and swaps slint → slint-keyos-platform at integration. All required permissions (os/security, os/keycard, os/backup) already exist. Recovery is security.set_seed → backup.restore_backup, with no new KeyOS APIs.
Dig into the source
README, architecture notes, and the wire protocol live in the repo.