diff options
Diffstat (limited to 'news/phase4-shamir-heir-recovery')
| -rw-r--r-- | news/phase4-shamir-heir-recovery/index.html | 199 | ||||
| -rw-r--r-- | news/phase4-shamir-heir-recovery/index.html.gz | bin | 0 -> 4586 bytes |
2 files changed, 199 insertions, 0 deletions
diff --git a/news/phase4-shamir-heir-recovery/index.html b/news/phase4-shamir-heir-recovery/index.html new file mode 100644 index 0000000..3acf79a --- /dev/null +++ b/news/phase4-shamir-heir-recovery/index.html @@ -0,0 +1,199 @@ +<!DOCTYPE html> +<html lang="en"> +<head> + <meta charset="utf-8"> + <meta name="viewport" content="width=device-width, initial-scale=1"> + <title>Phase 4: Heir Key Recovery with Shamir's Secret Sharing — Tesseras</title> + <meta name="description" content="Tesseras now lets you split your cryptographic identity into shares distributed to trusted heirs — any threshold of them can reconstruct your keys, but fewer reveal nothing."> + <!-- Open Graph --> + <meta property="og:type" content="article"> + <meta property="og:title" content="Phase 4: Heir Key Recovery with Shamir's Secret Sharing"> + <meta property="og:description" content="Tesseras now lets you split your cryptographic identity into shares distributed to trusted heirs — any threshold of them can reconstruct your keys, but fewer reveal nothing."> + <meta property="og:image" content="https://tesseras.net/images/social.jpg"> + <meta property="og:image:width" content="1200"> + <meta property="og:image:height" content="630"> + <meta property="og:site_name" content="Tesseras"> + <!-- Twitter Card --> + <meta name="twitter:card" content="summary_large_image"> + <meta name="twitter:title" content="Phase 4: Heir Key Recovery with Shamir's Secret Sharing"> + <meta name="twitter:description" content="Tesseras now lets you split your cryptographic identity into shares distributed to trusted heirs — any threshold of them can reconstruct your keys, but fewer reveal nothing."> + <meta name="twitter:image" content="https://tesseras.net/images/social.jpg"> + <link rel="stylesheet" href="https://tesseras.net/style.css?h=21f0f32121928ee5c690"> + + + <link rel="alternate" type="application/atom+xml" title="Tesseras" href="https://tesseras.net/atom.xml"> + + + <link rel="icon" type="image/png" sizes="32x32" href="https://tesseras.net/images/favicon.png?h=be4e123a23393b1a027d"> + +</head> +<body> + <header> + <h1> + <a href="https://tesseras.net/"> + <img src="https://tesseras.net/images/logo-64.png?h=c1b8d0c4c5f93b49d40b" alt="Tesseras" width="40" height="40" class="logo"> + Tesseras + </a> + </h1> + <nav> + + <a href="https://tesseras.net/about/">About</a> + <a href="https://tesseras.net/news/">News</a> + <a href="https://tesseras.net/releases/">Releases</a> + <a href="https://tesseras.net/faq/">FAQ</a> + <a href="https://tesseras.net/subscriptions/">Subscriptions</a> + <a href="https://tesseras.net/contact/">Contact</a> + + </nav> + <nav class="lang-switch"> + + <strong>English</strong> | <a href="/pt-br/news/phase4-shamir-heir-recovery/">Português</a> + + </nav> + </header> + + <main> + +<article> + <h2>Phase 4: Heir Key Recovery with Shamir's Secret Sharing</h2> + <p class="news-date">2026-02-15</p> + <p>What happens to your memories when you die? Until now, Tesseras could preserve +content across millennia — but the private and sealed keys died with their +owner. Phase 4 continues with a solution: Shamir's Secret Sharing, a +cryptographic scheme that lets you split your identity into shares and +distribute them to the people you trust most.</p> +<p>The math is elegant: you choose a threshold T and a total N. Any T shares +reconstruct the full secret; T-1 shares reveal absolutely nothing. This is not +"almost nothing" — it is information-theoretically secure. An attacker with one +fewer share than the threshold has exactly zero bits of information about the +secret, no matter how much computing power they have.</p> +<h2 id="what-was-built">What was built</h2> +<p><strong>GF(256) finite field arithmetic</strong> (<code>tesseras-crypto/src/shamir/gf256.rs</code>) — +Shamir's Secret Sharing requires arithmetic in a finite field. We implement +GF(256) using the same irreducible polynomial as AES (x^8 + x^4 + x^3 + x + 1), +with compile-time lookup tables for logarithm and exponentiation. All operations +are constant-time via table lookups — no branches on secret data. The module +includes Horner's method for polynomial evaluation and Lagrange interpolation at +x=0 for secret recovery. 233 lines, exhaustively tested: all 256 elements for +identity/inverse properties, commutativity, and associativity.</p> +<p><strong>ShamirSplitter</strong> (<code>tesseras-crypto/src/shamir/mod.rs</code>) — The core +split/reconstruct API. <code>split()</code> takes a secret byte slice, a configuration +(threshold T, total N), and the owner's Ed25519 public key. For each byte of the +secret, it constructs a random polynomial of degree T-1 over GF(256) with the +secret byte as the constant term, then evaluates it at N distinct points. +<code>reconstruct()</code> takes T or more shares and recovers the secret via Lagrange +interpolation. Both operations include extensive validation: threshold bounds, +session consistency, owner fingerprint matching, and BLAKE3 checksum +verification.</p> +<p><strong>HeirShare format</strong> — Each share is a self-contained, serializable artifact +with:</p> +<ul> +<li>Format version (v1) for forward compatibility</li> +<li>Share index (1..N) and threshold/total metadata</li> +<li>Session ID (random 8 bytes) — prevents mixing shares from different split +sessions</li> +<li>Owner fingerprint (first 8 bytes of BLAKE3 hash of the Ed25519 public key)</li> +<li>Share data (the Shamir y-values, same length as the secret)</li> +<li>BLAKE3 checksum over all preceding fields</li> +</ul> +<p>Shares are serialized in two formats: <strong>MessagePack</strong> (compact binary, for +programmatic use) and <strong>base64 text</strong> (human-readable, for printing and physical +storage). The text format includes a header with metadata and delimiters:</p> +<pre><code>--- TESSERAS HEIR SHARE --- +Format: v1 +Owner: a1b2c3d4e5f6a7b8 (fingerprint) +Share: 1 of 3 (threshold: 2) +Session: 9f8e7d6c5b4a3210 +Created: 2026-02-15 + +<base64-encoded MessagePack data> +--- END HEIR SHARE --- +</code></pre> +<p>This format is designed to be printed on paper, stored in a safe deposit box, or +engraved on metal. The header is informational — only the base64 payload is +parsed during reconstruction.</p> +<p><strong>CLI integration</strong> (<code>tesseras-cli/src/commands/heir.rs</code>) — Three new +subcommands:</p> +<ul> +<li><code>tes heir create</code> — splits your Ed25519 identity into heir shares. Prompts for +confirmation (your full identity is at stake), generates both <code>.bin</code> and +<code>.txt</code> files for each share, and writes <code>heir_meta.json</code> to your identity +directory.</li> +<li><code>tes heir reconstruct</code> — loads share files (auto-detects binary vs text +format), validates consistency, reconstructs the secret, derives the Ed25519 +keypair, and optionally installs it to <code>~/.tesseras/identity/</code> (with automatic +backup of the existing identity).</li> +<li><code>tes heir info</code> — displays share metadata and verifies the checksum without +exposing any secret material.</li> +</ul> +<p><strong>Secret blob format</strong> — Identity keys are serialized into a versioned blob +before splitting: a version byte (0x01), a flags byte (0x00 for Ed25519-only), +followed by the 32-byte Ed25519 secret key. This leaves room for future +expansion when X25519 and ML-KEM-768 private keys are integrated into the heir +share system.</p> +<p><strong>Testing</strong> — 20 unit tests for ShamirSplitter (roundtrip, all share +combinations, insufficient shares, wrong owner, wrong session, threshold-1 +boundary, large secrets up to ML-KEM-768 key size). 7 unit tests for GF(256) +arithmetic (exhaustive field properties). 3 property-based tests with proptest +(arbitrary secrets up to 5000 bytes, arbitrary T-of-N configurations, +information-theoretic security verification). Serialization roundtrip tests for +both MessagePack and base64 text formats. 2 integration tests covering the +complete heir lifecycle: generate identity, split into shares, serialize, +deserialize, reconstruct, verify keypair, and sign/verify with reconstructed +keys.</p> +<h2 id="architecture-decisions">Architecture decisions</h2> +<ul> +<li><strong>GF(256) over GF(prime)</strong>: we use GF(256) rather than a prime field because +it maps naturally to bytes — each element is a single byte, each share is the +same length as the secret. No big-integer arithmetic, no modular reduction, no +padding. This is the same approach used by most real-world Shamir +implementations including SSSS and Hashicorp Vault.</li> +<li><strong>Compile-time lookup tables</strong>: the LOG and EXP tables for GF(256) are +computed at compile time using <code>const fn</code>. This means zero runtime +initialization cost and constant-time operations via table lookups rather than +loops.</li> +<li><strong>Session ID prevents cross-session mixing</strong>: each call to <code>split()</code> generates +a fresh random session ID. If an heir accidentally uses shares from two +different split sessions (e.g., before and after a key rotation), +reconstruction fails cleanly with a validation error rather than producing +garbage output.</li> +<li><strong>BLAKE3 checksums detect corruption</strong>: each share includes a BLAKE3 checksum +over its contents. This catches bit rot, transmission errors, and accidental +truncation before any reconstruction attempt. A share printed on paper and +scanned back via OCR will fail the checksum if a single character is wrong.</li> +<li><strong>Owner fingerprint for identification</strong>: shares include the first 8 bytes of +BLAKE3(Ed25519 public key) as a fingerprint. This lets heirs verify which +identity a share belongs to without revealing the full public key. During +reconstruction, the fingerprint is cross-checked against the recovered key.</li> +<li><strong>Dual format for resilience</strong>: both binary (MessagePack) and text (base64) +formats are generated because physical media has different failure modes than +digital storage. A USB drive might fail; paper survives. A QR code might be +unreadable; base64 text can be manually typed.</li> +<li><strong>Blob versioning</strong>: the secret is wrapped in a versioned blob (version + +flags + key material) so future versions can include additional keys (X25519, +ML-KEM-768) without breaking backward compatibility with existing shares.</li> +</ul> +<h2 id="what-comes-next">What comes next</h2> +<ul> +<li><strong>Phase 4 continued: Resilience and Scale</strong> — advanced NAT traversal +(STUN/TURN), performance tuning (connection pooling, fragment caching, SQLite +WAL), security audits, institutional node onboarding, OS packaging</li> +<li><strong>Phase 5: Exploration and Culture</strong> — public tessera browser by +era/location/theme/language, institutional curation, genealogy integration, +physical media export (M-DISC, microfilm, acid-free paper with QR)</li> +</ul> +<p>With Shamir's Secret Sharing, Tesseras closes the last critical gap in long-term +preservation. Your memories survive infrastructure failures through erasure +coding. Your privacy survives quantum computers through hybrid encryption. And +now, your identity survives you — passed on to the people you chose, requiring +their cooperation to unlock what you left behind.</p> + +</article> + + </main> + + <footer> + <p>© 2026 Tesseras Project. <a href="/atom.xml">News Feed</a> · <a href="https://git.sr.ht/~ijanc/tesseras">Source</a></p> + </footer> +</body> +</html> diff --git a/news/phase4-shamir-heir-recovery/index.html.gz b/news/phase4-shamir-heir-recovery/index.html.gz Binary files differnew file mode 100644 index 0000000..f4b1598 --- /dev/null +++ b/news/phase4-shamir-heir-recovery/index.html.gz |