Shamir Secret Sharing for HGT + multi-tenant shards — design exploration

[SwiftWing21]

Shamir Secret Sharing for HGT + multi-tenant shards — design exploration

Filed by raude — Claude Code Opus 4.6 (1M context). Design-note discussion, not a ticket. Captures a future direction so it doesn't get lost in chat scrollback.

Origin

During the 2026-04-10 session the user flagged a BuildStuff conference talk by Tejas Chopra on Shamir Secret Sharing (SSS) — the same Tejas whose Headroom toolkit we just adopted in v0.3.0b5. The (joking) question was "does this help audio ingestion, and is it already in Tejas's tools?" The serious answer is no — Headroom is LLM compression, SSS is cryptography, and they don't meaningfully intersect the audio problem. But SSS does intersect helix-context in three other places that are worth writing down before we forget.

What SSS is (one-paragraph refresher)

Shamir Secret Sharing takes a secret S and splits it into N shares using polynomial interpolation. Any K shares (the threshold) can reconstruct S via Lagrange interpolation; strictly fewer than K shares reveal zero information — information-theoretic security, not computational, meaning even unbounded compute can't extract the secret from K-1 shares. There's no key, no algorithm attack surface, no post-quantum concern. Just math.

Where SSS would shine in helix-context

1. Privacy-preserving Horizontal Gene Transfer (hgt.py)

Today hgt.py exports full genes to .helix files and re-imports them on another Helix instance. Gene content is cleartext, which is fine for public knowledge but blocks any scenario where two parties want to share derived understanding without exposing the raw source. Examples:

• A law firm and a client sharing case knowledge without the firm's database being ingestible wholesale
• BigEd fleet A and fleet B under different SLAs exchanging learned patterns
• Two research groups pooling embedding data without sharing raw corpora

SSS-backed HGT: instead of exporting Gene.content, export {gene_id, [share_1, share_2, share_3]} where each share goes to a different party. Any 2 of 3 parties can reconstruct the gene; no single party can. The biology metaphor lands perfectly — actual biological HGT involves fragment transfer with reconstruction at the recipient.

This is genuinely novel. I could not find a single paper or production system titled "federated RAG with information-theoretic secrecy across shards." Someone should build it; helix-context is positioned for it.

2. Multi-tenant enterprise genome isolation (v0.400 roadmap)

The ROADMAP.md already has multi-tenant SaaS as a v0.400 concern. SSS could back a "genome shard" architecture where:

• Tenant A's genes live as 2-of-3 SSS shares across A's private storage cluster
• Tenant B's shards never overlap with A's
• Single-shard compromise is ITS-secure (no compute advantage to the attacker)
• The control plane holds routing metadata but never reconstructs gene content
• Post-quantum safe as a bonus

This pairs naturally with the existing [genome] replicas config in helix.toml — today replicas are simple mirrors (every replica has the full DB), tomorrow they could be SSS shards with a configurable threshold and share_count.

3. Audit-logged gene unlocking with K-of-N approvers

For sensitive genes (medical records, legal filings, HR notes, board minutes), encrypt the gene content with a key, then SSS-split the key across N approvers. Reading the gene requires K of them to co-sign a reconstruction. Every reconstruction is logged: who provided their share, when, and what gene was unlocked.

This maps onto helix's existing chromatin state — add a new LOCKED state that requires K-of-N to demote back to OPEN for a query.

Where SSS does NOT help

• Audio ingestion (the thing that triggered this discussion). Different problem. A CLAP embedding of a dog bark is not a secret that needs polynomial interpolation. SSS could sit under an audio gene if the audio is sensitive, but that's a storage concern, not an audio concern.
• Compression. SSS is not compression — the sum of N shares is actually larger than the secret. Use Headroom for compression, SSS for distribution.
• Retrieval quality. SSS doesn't affect whether retrieval finds the right gene; it only affects whether the right gene can be read once found. Bolt SSS on top of retrieval, not into it.
• Per-gene query-time performance. Reconstructing a gene from K shares requires contacting K stores and doing Lagrange interpolation. Adds latency. Viable for cold-storage HETEROCHROMATIN genes, probably overkill for hot OPEN genes.

Engineering scope estimate (if this ever becomes a real ticket)

Piece	Size
Pure-Python SSS implementation (prime field, k and n configurable) OR adopt an existing library like pysss or secretsharing	~1 day
helix_context/sss_bridge.py wrapper (lazy import, optional extra)	~0.5 day
hgt.py export mode: --threshold K --shares N --parties file1,file2,file3	~1 day
hgt.py import mode: reconstruct from K of N share files	~0.5 day
Tests covering the K-1 reveals nothing / K reveals everything invariant	~0.5 day
Integration with replica config in helix.toml (replace mirror mode with shard mode)	~2 days — touches more surface
LOCKED chromatin state + K-of-N unlocking workflow + audit log	~3 days — touches schemas.py, genome.py, HTTP layer
Docs + threat model writeup	~1 day

Total first meaningful slice (HGT export/import only): ~4 days. Not an MVP for v0.4.0 — more like a v0.5.0 or v0.4.x stretch goal, depending on whether federated/multi-tenant work picks up.

Why file this as a design discussion, not an issue

The three use cases above are all "future direction" rather than "open bug." Discussion is the right venue for capturing the exploration without committing to a sprint. When the SaaS/multi-tenant work picks up, the search for "how do we do federated storage" will surface this, and the implementer won't have to re-derive the design from scratch.

Adjacent reading

• Shamir, A. (1979) "How to share a secret" — the original paper
• pysss — pure-Python SSS implementation
• Tejas Chopra's broader storage + distributed systems work — the BuildStuff talk referenced in the session that triggered this note

A note on scope honesty

helix-context is a single-machine genome today. SSS is a multi-party primitive. Adopting SSS for its own sake on a single machine is wasteful (the whole secret lives in the same process anyway). SSS only pays off when there are multiple parties or multiple trust domains involved — federated fleets, multi-tenant SaaS, encrypted rest-state with audit-logged unlock. If helix-context never goes federated, this note stays filed as "explored but not needed." That's a valid outcome.

---

— raude, Claude Code Opus 4.6 (1M context)
Session: 2026-04-10 / helix-context v0.3.0b5 / research thread branching off audio ingestion