chela GitHub

A tour of the codebase

chela is one Cargo workspace of ten crates. The lower half is the cryptographic core: primitives, field arithmetic, secret sharing, BIP-39 encoding, and the engine that orchestrates them. The upper half is user-facing: share formatting, the interactive TUI, the scriptable CLI, the WASM FFI, and the self-contained HTML bundle. Each layer depends only on the layers below it; nothing in the upper half is imported by the lower half.

How the crates depend on each other

flowchart TB
  field[chela-field] --> sss[chela-sss]
  prim[chela-primitives] --> sss
  prim --> bip[chela-bip39]
  sss --> engine[chela-engine]
  bip --> engine
  engine --> share[chela-share]
  share --> tui[chela-tui]
  share --> cli[chela-cli]
  share --> wasm[chela-wasm]
  wasm --> bundle[chela-bundle]
        
Dependency tree of the chela workspace. chela-field and chela-primitives sit at the top with no dependencies. chela-sss builds on both; chela-bip39 builds on chela-primitives. Both feed chela-engine, which feeds chela-share, which feeds the three front-ends chela-tui, chela-cli, and chela-wasm. chela-bundle embeds the compiled chela-wasm at build time.
The main dependency edges of the chela workspace. Each crate's complete list is in its Cargo.toml. The chela-bundle edge is a build-time relationship: its build script compiles and embeds chela-wasm.

What each crate does

chela-primitives/

The foundation layer. Provides SHA-256 (hand-written, no third-party crate), constant-time byte equality (ct_eq), a volatile_set primitive for zeroing secret-bearing buffers without the compiler optimizing the write away, and a thin wrapper around the OS random-number generator. Every security-sensitive operation in the workspace ultimately bottoms out here. The SHA-256 here is used only by chela-bip39 to validate a mnemonic's built-in checksum on recovery; the share engine uses none - its per-share checksum is an 11-bit CRC and its recovery set id is a random nonce.

chela-field/

Constant-time arithmetic over GF(2^8), the finite field of 256 elements. Addition is XOR; multiplication is a branch-free shift-and-XOR loop of eight unconditional rounds, with the reduction modulo the Rijndael polynomial 0x11b driven by bit masks rather than branches. No lookup tables: a table indexed by secret bytes would leak via the CPU cache, so every operation runs in data-independent time and share values cannot be recovered through a timing side-channel. This crate has no dependencies at all.

chela-sss/

The Shamir Secret Sharing implementation. split samples a random polynomial of degree M−1 over GF(2^8) and evaluates it at N distinct x-coordinates, one per share. The engine draws those x-coordinates at random from 1..32 rather than handing out a sequential 1..N, so a share leaks neither the total count nor its position. combine runs Lagrange interpolation to recover the polynomial's constant term. Each byte of the secret is processed independently; a 24-word BIP-39 seed (32 bytes of entropy) produces 32 independent single-byte polynomials.

chela-bip39/

BIP-0039 codec plus the 2048-word English wordlist, compiled in at build time. Converts between raw entropy bytes and the mnemonic word sequence, including the checksum appended to the last word. Also used to encode share bytes as word lists on the printed shares so a human can transcribe a share using only a pen.

chela-engine/

Orchestration layer. Calls chela-sss for the core math and chela-bip39 for encoding. To split, it draws an 11-bit generation recovery set id and N random distinct x-coordinates, appends the kind byte to the body and Shamir-splits the whole thing - so the payload type stays hidden until recovery - then encodes each share into the wire format defined in SPEC.md: word 0 packs [x, M], word 1 is the recovery set id, the middle words are the Shamir output, and the last word is an 11-bit CRC. Recovery is the inverse: decode and CRC-verify each share's words, check they share one recovery set id and threshold, Lagrange-combine, then read the kind from the recovered body's last byte. No split identifier, no SHA-256.

chela-share/

Share presentation layer. Takes the raw share bytes from chela-engine and renders them as: a plain-text share (the word list plus metadata), a JSON object for programmatic use, and a printable paper-backup HTML page styled to fit on a standard index card. Its parser is the one place chela reads externally supplied text, so the fuzz harness lives here too.

chela-tui/

The interactive terminal wizard. Walks the user through split or recovery with prompts and confirmation steps, then prints each share to the terminal for transcription or saving. Intended for users who want a guided experience. Depends on chela-engine; does not touch the crypto directly.

chela-cli/

The scriptable command-line interface. Takes flags rather than interactive prompts: the secret arrives via --mnemonic or --text, shares print to stdout, and the --paper / --json flags write paper-backup or JSON files instead. Suited for automation, shell scripts, and users comfortable with the command line. The same engine and encoding as the TUI; different surface only.

chela-wasm/

A WebAssembly FFI wrapper around chela-engine and chela-share. The C-ABI is hand-rolled - no wasm-bindgen, no third-party crates. The exports are chela_alloc and chela_dealloc for memory management, plus chela_split, chela_recover, chela_render_paper_html, chela_render_shares_json, chela_extract_shares, and chela_word_in_list for the actions. JS passes inputs as a tagged binary format and reads JSON back; the cryptographic core does not depend on any browser API. Compiled to a .wasm binary that is base64-embedded into the standalone bundle.

chela-bundle/

Build tool that assembles the standalone chela.html. Inlines the compiled WASM binary (base64), the JavaScript glue, and the UI into a single self-contained HTML file that runs entirely in the browser with no network requests. The file you download from the release page is produced by this crate.

Going deeper

To see how these crates combine into the words on a share, read the share format. For the exact byte layout, the cryptographic reasoning, and the tests behind each claim, see SPEC.md and AUDITORS.md.