What chela defends against (and what it doesn't)
chela has a well-defined perimeter. Inside it: the mathematics of secret sharing, the encoding of shares onto shares, and the verification machinery that catches transcription errors and cross-split contamination. Outside it: the machine you run chela on, the browser that executes the standalone bundle, the people you hand shares to, and the build pipeline that produced the binary. Knowing where the perimeter falls tells you exactly where your own due diligence begins.
Defended attacks
| Attack | How chela defends |
|---|---|
| Loss or leak of fewer than M shares |
Information-theoretic: any subset smaller than the threshold reveals zero
information. Each share is one point on a polynomial of degree M−1; with
fewer than M points, infinitely many polynomials fit, each consistent with
a different secret. Fewer than M shares leave the secret
information-theoretically undetermined - there is nothing to brute-force.
chela-sss::split |
| A single transcription error on a share |
The last word of every share is an 11-bit CRC-11/UMTS checksum over the
share's decoded values - its x-coordinate, threshold, the recovery set id,
and its Shamir output bytes. A mistyped word changes at most 11 contiguous
bits, and an 11-bit CRC catches every burst error that short. Recovery
rejects the share with ShareCorrupt before any secret material
is assembled.
chela-engine::decode_share_bip39_v2 |
| Shares from two unrelated splits accidentally combined |
Every share carries an 11-bit recovery set id (a nonce) - a random value drawn once
per split from the OS CSPRNG and written identically into all of that
split's shares. Recovery rejects any set whose nonces disagree with
MismatchedShares. The recovery set id is not a hash of the secret, so it
leaks nothing about a low-entropy payload, and re-splitting the same secret
draws a fresh recovery set id - so even those two runs are correctly refused.
chela-engine::recover_secret |
Undefended attacks
| Attack | What you should do |
|---|---|
| Tampered build artifact |
Verify the minisign signature against the public key published in
README.md before running the binary. chela ships a
SHA256SUMS file and a .minisig for every release
asset; the verification commands are in README.md.
|
| Coalition of M or more shareholders | Choose trusted, geographically distributed shareholders. chela cannot defend against the people you handed shares to - the threshold is a quorum, not a safeguard against unanimous collusion. |
| Compromised host machine | Run recovery on an air-gapped machine. Clipboard sniffers, swap, and hibernation files are outside chela's reach. For the highest-assurance case, boot from a live USB and recover on a machine that has never connected to a network. |
| Compromised browser running the bundle |
Verify the SHA-256 of the standalone chela.html against the
SHA256SUMS published on the release page before opening it in a
browser. A browser extension or injected script with access to the page can
read DOM content.
|
| Forensic recovery of cleared scrollback | Use an ephemeral environment - a live USB, a throwaway VM, or a terminal with scrollback disabled - for sensitive recovery sessions. Cleared terminal scrollback may survive in swap, core dumps, or crash logs. |
Where chela's perimeter ends
flowchart TB
subgraph outside["Outside chela's perimeter - you handle these"]
host[Compromised host machine]
build[Tampered build artifact]
coalition[Coalition of M+ shareholders]
browser[Compromised browser]
end
subgraph chela_perimeter["chela's perimeter - chela handles these"]
sss[Shamir split / combine]
rng[OS RNG calls]
enc[Share encoding & checksums]
bip[BIP-39 codec]
end
