Review request: combining age (scrypt passphrase) with Shamir secret sharing for offline, browser-based recovery

Hi r/crypto,

I’m looking for technical critique of a small tool I built that combines **age** encryption with **Shamir’s Secret Sharing** and a **self-contained browser recovery tool**.

Repo: [https://github.com/eljojo/rememory](https://github.com/eljojo/rememory)
Docs: [https://eljojo.github.io/rememory/docs.html](https://eljojo.github.io/rememory/docs.html)

# Problem I’m trying to solve

How can non-technical people recover encrypted secrets if the owner is suddenly unavailable, **without**:

* trusting any single person
* trusting any server or service to exist
* requiring software installation at recovery time

This is related to “dead man switch” / inheritance ideas, but the design goal here is **offline, human-operable recovery** with minimal moving parts.

# High-level design

When sealing:

1. Generate a random 256-bit passphrase from `crypto/rand`
2. Encrypt a folder (`manifest/`) using **age** in **scrypt passphrase mode**
3. Split the passphrase into N shares with threshold T using **Shamir’s Secret Sharing over GF(2\^8)**
4. Produce per-person bundles containing:
* their share
* the encrypted archive (`MANIFEST.age`)
* a single `recover.html` file (Go compiled to WASM)

When recovering:

* Someone opens `recover.html` in any modern browser (no network)
* Multiple people provide their share files
* The WASM code reconstructs the passphrase
* The manifest is decrypted locally in the browser
* Files are offered for download

No servers, no accounts, no dependencies on the project existing later.

# Algorithms / components

* Encryption: [https://github.com/FiloSottile/age](https://github.com/FiloSottile/age) (scrypt passphrase mode)
* KDF parameters: age defaults (scrypt N=2^(20,) r=8, p=1)
* Secret sharing: Shamir over GF(2^(8)) (inspired by HashiCorp Vault’s implementation)
* Integrity: SHA-256 checksums on share files
* Recovery tool: Go → WASM embedded into a single HTML file

No custom cryptography; this is composition of existing primitives.

# Threat model

Assumes:

* At least T share holders keep their bundle safe
* The machine used at recovery time is not compromised
* The sealing machine is trusted at the time of sealing

Does not rely on:

* Any server
* Any online service
* The repo or project existing in the future

# What I’d like critique on

* Using age in passphrase mode for this purpose
* The Shamir implementation choices (GF(2^(8)))
* The composition of these pieces for this use case
* Any obvious failure modes I’m missing
* Long-term viability of WASM-in-HTML as a recovery vehicle

I’m aware that “dead man switches” and legal/safe approaches exist. What feels different here is that the **recovery artifact is a single static file** that someone mildly technical (e.g., my brother) can use without installing anything or trusting infrastructure.

# Similar tools and how they compare

There are a few other projects that use secret splitting / file fragment approaches that I only learned about *after* I started ReMemory:

* **Horcrux** ([https://github.com/jesseduffield/horcrux](https://github.com/jesseduffield/horcrux))
* **Horcrux (TS version)** ([https://github.com/nao1215/horcrux](https://github.com/nao1215/horcrux))
* **Haystack** ([https://github.com/henrysdev/Haystack](https://github.com/henrysdev/Haystack))

All of these demonstrate the *same core cryptographic primitive*: split a secret into pieces that can be recombined with a threshold. What sets **ReMemory** apart is the focus on **end-user recovery usability**:

* the bundles are zipped with clear `README.txt` and `README.pdf` for printing,
* the key recovery and decryption works entirely offline **in a browser with no install or runtime dependencies**, and
* the intent is that someone *mildly technical* (e.g., my brother) can use this to recover data without being a developer.

If you think existing approaches already does this, I’d be very interested in that comparison; from my exploration, they all stop at key splitting or file splitting and leave the recovery UX to the user’s own tooling.

# AI disclosure (per rules)

Wording in this post and code has been assisted by an LLM. I have 20+ years of software engineering expertise, everything has been carefully hand reviewed.

Prompt used:

>“Explain this project to a cryptography audience. Focus on algorithms, threat model, and composition. Avoid marketing language. Ask for critique.”

Happy to clarify anything or point to specific code paths.

Thanks for taking a look.