Security model · v1.0.4

Security without custody.

Shards does not store your secret, your shards, or your recovery plan. Sensitive operations happen locally in your browser — and the source is open, so you don't have to take our word for it.

i · Architecture

Where the work happens.

Three columns. The first is what your browser does. The second is what our server does. The third is what never leaves your device under any circumstance.

Browser
  • secret_input
  • shamir_split
  • shard_generation
  • pdf_render
  • qr_render
  • recovery
  • memory_clear
Server
  • static_html
  • static_css
  • static_js
  • fonts
  • icons
  • — nothing else —
  • no logging, no analytics
Never transmitted
secret shards reconstructed_secret holder_labels session_metadata
ii · Guarantees

What we commit to.

Eight properties of the protocol. Each is testable — by reading the source, watching network traffic, or running the tool offline.

Browser-only processing

All cryptographic work runs in your browser. No remote computation.

No server-side storage

Our server holds the static app files. It does not see your data.

No account required

No email, no login, no profile. The tool is anonymous by design.

Open-source code

Every line is on GitHub. Cloneable, auditable, runnable offline.

M-of-N threshold

Any M of N shards reconstruct. Standard Shamir secret sharing.

Sub-threshold reveals nothing

Fewer than M shards yield zero information about the secret.

Offline-capable

Once loaded, the app works without internet. Cache it, run it later.

Clear local session

One button removes everything. Browser memory is the only memory.

iii · Quantum

Quantum-safe threshold backup.

The threshold split itself does not depend on computational hardness.

Shamir's Secret Sharing is information-theoretically secure when implemented correctly. Fewer than the required number of shards reveal no information about the secret — to a classical computer, a quantum computer, or any other computer that may exist in the future.

That isn't because we found a faster algorithm. It's because the missing information is not encoded in the available shards at all. The polynomial that interpolates 2 points in a 3-of-5 scheme has infinitely many extensions to a third point. Every possible secret remains equally consistent with what an attacker can see.

Precise claim: the threshold split itself does not rely on computational hardness. Other risks — such as malware on the device performing the split, phishing of the recovering party, browser extension key-loggers, or compromised printers — are outside the cryptographic guarantee. Quantum-safe is a property of the math, not a property of the room you're standing in.

iv · Mathematics

How 3 of 5 works.

A polynomial of degree M − 1 has exactly M coefficients. The secret is one of them. The shards are points the polynomial passes through.

# the secret is the constant term secret = f(0)   # pick a random degree-2 polynomial f(x) = secret + a1x + a2x2   # 5 shards = 5 points on the curve shards = f(1), f(2), f(3), f(4), f(5)   # any 3 points determine f, hence f(0) recover = any 3 points → f(0)   # 2 points fit infinite parabolas 2 points → unbounded ambiguity
0 1 2 3 4 5 f(x) f(0) · secret i ii iii iv v true polynomial other curves through 2 pts
In a 3-of-5 setup, two shards are not almost enough.
Infinitely many polynomials pass through any two points.
v · Threat model

What we protect, what we don't.

Threshold custody solves one specific problem — the single point of failure. It is not a substitute for general operational security. We are explicit about both sides.

Protected against

Things the threshold scheme defeats by design.
  • One lost shard.
  • One stolen shard.
  • One compromised holder.
  • One house fire or local theft.
  • Eternalink-style company shutdown.
  • Single-point custody failure.
  • One person having unilateral recovery power.

Not protected against

Risks outside the cryptographic guarantee.
  • Malware on the splitting or recovery device.
  • A spoofed Shards website (phishing).
  • Browser extensions reading input fields.
  • Printer memory retaining print jobs.
  • Screenshots or cloud-synced clipboards.
  • Storing all shards in one location.
  • Losing too many shards to meet the threshold.
  • Mistyping the original secret before splitting.
vi · Best practices

Eight rules for real deployments.

The cryptography only protects what the procedure preserves. These rules close the gaps the math cannot.

  • Test first with a dummy secret. Verify the recovery before splitting anything you cannot afford to lose.
  • Use offline mode for high-value secrets. Disconnect from the internet after the page has loaded.
  • Store shards in different physical locations. The threshold protection assumes physical separation.
  • Do not photograph all shards together. One image with five shards defeats five-point distribution.
  • Do not email all shards to yourself. Email is one location, no matter how many addresses you use.
  • Use a trusted printer or write shards by hand. Office printers commonly retain print jobs in memory.
  • Keep recovery instructions with each shard. Holders should know how to use what they hold.
  • Tell trusted holders what their shard is for. Silent shards are often discarded as junk.
vii · Open source

Trust the code, not the company.

The product is the source code. Everything else — this domain, our copy, our brand — is auxiliary. If we vanish tomorrow, your shards still recover.

The repository & its guarantees.

Six artifacts published alongside the code. Each is independently verifiable.

Repository github.com/shards-app Public · MIT
License MIT Permissive · forkable
Security policy SECURITY.md Disclosure · 90 days
Build instructions Reproducible SHA-256 verified
Test vectors SLIP-39 conformant 214 / 214 passing
Audit status Trail of Bits · Q2 2025 Scheduled

Run it yourself · 7 steps

~ 4 minutes
  • 01 $ git clone github.com/shards-app/shards
  • 02 $ cd shards && npm install
  • 03 $ npm test # 214 tests, ~30s
  • 04 $ npm run build # reproducible build
  • 05 $ ifconfig wlan0 down # go offline
  • 06 $ open dist/index.html
  • 07 → split or recover, fully offline.
viii · FAQ

Questions we get.

No. Shards never receives or stores your secret or shards. Recovery requires possession of M of the N shards you generated. If those are lost below the threshold, the secret cannot be recovered — by us or anyone.
The secret cannot be recovered. The same property that makes 2 or fewer shards reveal nothing also makes M − 1 shards reveal nothing. The privacy guarantee cuts both ways.
No — not unless they collude with enough other holders to meet the threshold. A single shard reveals nothing useful about the secret. This is the core property of Shamir's scheme.
No. It works for any short secret: BIP-39 seed phrases, Ethereum private keys, password manager master passwords, recovery codes, encryption keys, or arbitrary text up to 4 KB.
It is different. Multisig controls signing — multiple parties cooperate to authorize each transaction. Shards protects backup and recovery secrets — multiple parties cooperate to reconstruct a key that may then be used however the owner intended. They are complementary, not substitutes.
Yes, and we recommend it for high-value secrets. Load the page once, disconnect from the internet, then split or recover. The codebase can also be cloned and run locally — see the verification steps above.
Each printed shard card includes recovery instructions referencing both shards.app and any SLIP-39 compatible tool. The math is standard. The format is a published standard. Your shards remain recoverable through any compliant implementation, regardless of whether this specific domain still resolves.
Begin

Ready to remove the single point of failure?