1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
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>
|