ReMemory: Offline Recovery with Split Encryption Keys

Why ReMemory Uses Several Recovery Holders

ReMemory addresses a specific digital estate problem: important files become inaccessible when the person who arranged them can no longer guide their recovery. The README gives password manager recovery codes, cryptocurrency seeds, important documents, and instructions for loved ones as examples. The intended users are not cryptographic specialists, but people who can follow prepared instructions and bring their bundles together when needed.

The design avoids assigning the complete secret to one holder. During preparation, ReMemory chooses a threshold such as 2-of-3, 3-of-5, or 2-of-2. Every participant receives a separate bundle containing one key piece. Recovery succeeds only when enough participants supply their pieces to one recovery page.

That cooperation requirement is both the security control and the operational dependency. A 3-of-5 arrangement can tolerate two unavailable holders, but it also requires the remaining participants to recognize the threshold, obtain the correct bundles, and complete recovery together. ReMemory removes dependence on a hosted account or permanent service, but it does not remove dependence on people.

The documented threat model is explicit. ReMemory assumes that at least the configured threshold will keep their bundles, will cooperate when needed, and will use an uncompromised browser. It also assumes that the device used to create the bundles is trusted. These assumptions make it more suitable for a prepared estate plan than for protection against a compromised creator device, a malicious browser, or recipients who fail to safeguard their files.

How age Encryption and Shamir Pieces Protect the Archive

The creation flow starts with local files. According to the README, ReMemory encrypts the selected data with age in scrypt passphrase mode, then generates a 256-bit passphrase from `crypto/rand`. It divides that passphrase into shares using Shamir's Secret Sharing over GF(2^8). The chosen threshold determines how many shares are needed to reconstruct it.

A single share does not contain enough information to reveal the passphrase. The README describes this as a mathematical guarantee of Shamir's Secret Sharing rather than a password-strength property. Once the required number of shares is present, the recovery tool reconstructs the passphrase and uses it to unlock the age-encrypted files. SHA-256 checksums provide an integrity layer for detecting mismatched or damaged inputs.

The README's security table identifies age encryption, scrypt with `N=2²⁰, r=8, p=1`, Shamir sharing over GF(2^8), and SHA-256 checksums. Optional time locking uses drand tlock with BLS12-381 IBE for an inner layer. The time-locked mode needs a brief internet connection at recovery time and is labeled experimental, so it should not be treated as interchangeable with the fully offline recovery path.

The repository layout shows two browser builds for recovery. The Makefile describes `app.js` as the offline build with tlock and drand code excluded, while `app-tlock.js` includes recovery components that communicate with drand. This separation limits network behavior for ordinary archives instead of placing every recovery mode in one bundle.

What Each ReMemory Recipient Receives

Each person receives a ZIP bundle rather than a request to install ReMemory or register with a service. The bundle contains `README.txt`, a printable `README.pdf`, and a browser-based `recover.html` file. Encrypted files appear as `MANIFEST.age` and are included separately when the archive is over 10 MB. For smaller archives, the README says the recovery data is embedded in the HTML file.

This format is the project's main operational advantage. The recovery tool is described as roughly 300 KB, running in a browser and containing no server-side dependency. The holder can open the page, add files from other participants, meet the threshold, and download the unlocked archive. ReMemory does not need to remain online for ordinary recovery, and the README says it does not need to exist when recovery happens.

Self-containment does not remove the need for custody. A missing ZIP, unreadable PDF, failed browser, or overwritten file can prevent one holder from participating. The bundle also has to reach the recovery scene, either as a whole directory or through files dragged onto the recovery page. The instructions in `README.txt` and `README.pdf` therefore matter as much as the cryptographic share.

A QR-code dependency appears in `go.mod` through `github.com/skip2/go-qrcode`, and the end-to-end JavaScript packages include barcode detection libraries. The README does not explain the complete QR-code workflow, so it would be unsafe to assume that scanning a code alone replaces bundle distribution or recovery.

Trying ReMemory Before Entering Real Secrets

The safest documented first exercise is ReMemory's published demo rather than a newly created private archive. The README links to `demo-bundles.zip` on the latest release page. The archive represents five friends with a 3-of-5 recovery arrangement.

Download `demo-bundles.zip`, extract it, and open `bundle-alice/recover.html` in a browser. Alice's share is already loaded in that page. Drag two README files from two other bundle directories onto the page, or drag entire bundles as the README states. The page should remain locked until enough shares have been added and should unlock the files after the third share is present.

The README links to this release-linked demo archive. The README does not specify operating-system-specific extraction commands, so extraction should be performed with the user's normal archive tool.

For a first private archive, the browser maker is the lower-friction path. Open `https://eljojo.github.io/rememory/maker.html`, add the chosen recipients, add files, configure the recovery requirements described by the interface, and generate the bundles. The README says this creation happens in the browser and that the selected files do not leave the device. It does not publish detailed maker field names, so this tutorial does not invent UI labels or configuration keys.

Before placing irreplaceable material into generated bundles, first complete the 3-of-5 demo and confirm the locked and unlocked states. Then repeat the same physical transfer method with the actual recipient count and threshold intended for the archive.

CLI and Container Paths for Repeatable Bundle Creation

ReMemory also provides a Go CLI and a self-hosted Docker image for automation or terminal use. The repository has a Go module named `github.com/eljojo/rememory`, Cobra command code under `cmd/`, and internal packages. The README does not include the CLI User Guide text, so it does not support a verified command example for creating a private bundle.

On macOS, the README gives a Homebrew installation command:

brew install eljojo/rememory/rememory

For Linux on x86_64, it documents downloading the released binary and placing it in `/usr/local/bin/`:

curl -Lo rememory https://github.com/eljojo/rememory/releases/latest/download/rememory-linux-amd64
chmod +x rememory
sudo mv rememory /usr/local/bin/

Nix offers a direct repository invocation:

nix run github:eljojo/rememory

The self-hosted image exposes port `8080` and stores its named volume at `/data`. Its documented command is:

docker run -d \
  --name rememory \
  -p 8080:8080 \
  -v rememory-data:/data \
  ghcr.io/eljojo/rememory:latest

The browser can then reach the service through `http://localhost:8080`, assuming the published port mapping is left unchanged. `docker-compose.yml` adds `restart: unless-stopped` and comments out an optional `REMEMORY_MAX_MANIFEST_SIZE` setting with a value of `200MB`. The README does not explain the default manifest limit, so operators should check `docs/selfhosted.md` before changing that setting.

Container deployment is useful for a maintained internal interface, but recovery itself still produces self-contained browser bundles. Host availability matters during creation, not as a requirement for ordinary offline recovery.

Time Locks, Custody Limits, and Alternative Recovery Models

Optional tlock recovery changes the offline guarantee. The README calls time-delayed recovery experimental and says these archives need a brief internet connection when recovery occurs. The drand dependency and separate `app-tlock.js` build support a delayed inner layer, but the README excerpt does not document a complete procedure for choosing an encryption time or handling drand outages. Users considering this mode need the full time-lock documentation before depending on it.

ReMemory is also the wrong tool when recovery must happen without human coordination. Its central requirement is that enough people bring shares together. It does not describe a dead-man's switch that automatically unlocks after inactivity, despite that phrase appearing among the repository topics. The documented behavior is cooperative recovery, not automatic release.

Password manager emergency access is a different approach because it relies on the provider's service and account system. ReMemory instead distributes self-contained shares among chosen people and states that ordinary recovery does not rely on its website or infrastructure. That removes provider availability from recovery, but transfers responsibility to bundle custody and participant availability.

Splitting files manually is another alternative named in the README. ReMemory wraps that approach with age encryption, Shamir shares, printable instructions, integrity checks, and a common recovery page. This is more opinionated than a manual encrypted archive because every holder receives the same workflow and the shares are generated for a specific threshold.

The repository is licensed under Apache-2.0. Users must follow that license's notice and other applicable terms when using or modifying the project. Bundle generation, recipient agreement, hardware retirement, backup copies, and the eventual transfer of instructions remain responsibilities outside the cryptographic threshold.

Maintenance Signals and Upgrade Work for Bundle Holders

The repository is not archived. Its last push was on 2026-09-19, and the listed releases include `v0.0.21`, `v0.0.20`, and `v0.0.19` from April 2026. These facts indicate recent repository activity, but the version remains below `1.0`, and the README does not promise compatibility across releases. The repository contains Go, TypeScript, browser assets, Playwright end-to-end tests, Docker configuration, and multiple documentation formats, so an upgrade is more involved than replacing one static file.

Existing recipient bundles are especially important. Because recovery is intended to work without the project, users should not assume that regenerating recipient files is mandatory. The README does not document migration between bundle formats or recovery-tool versions. It also does not document rollback. Anyone upgrading an active estate plan should preserve the previously distributed bundles and compare the new workflow before replacing them.

The repository's `Makefile` separates ordinary offline recovery assets from the tlock build. It also includes build, test, WebAssembly, TypeScript, documentation, and release targets, but the repository does not show enough of each target to reproduce a release from the README alone. The CLI and Docker paths use `latest`, which can change as new release assets are published. Organizations that require repeatable recovery tooling should record the selected binary or container image rather than relying only on the moving tag.

The upgrade cost is therefore concentrated in preparation and validation, not routine server hosting. Recipients should not need new accounts or configuration. The person responsible for the estate plan must still decide whether old bundles remain authoritative, whether a new threshold is needed, and whether experimental time-lock behavior belongs in the plan.

Editorial conclusion

ReMemory is suitable for families, couples, and small groups that can prepare, distribute, and retain numbered recovery bundles under an agreed threshold. It is a poor fit for unattended recovery, simultaneous mass access, or environments where recipients cannot safely keep browser files or PDF instructions. Before adoption, verify the recipient count and threshold, open the demo in a clean browser, confirm that the expected threshold unlocks the archive, and inspect whether optional time-locked recovery introduces an internet requirement that matches the estate plan.

Frequently asked questions

Official sources

1. eljojo/rememory on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases