Security
How envden protects files, verifies history and limits checkout access.
Files are encrypted on your devices
Your device encrypts files with XChaCha20-Poly1305 before upload. File names and Repo IDs are encrypted too. Files are padded in 256-byte steps to reduce size precision.
Each file's encryption binds it to the vault, encryption epoch, file ID and version. A signed manifest binds the ciphertext hashes. Devices verify the manifest and the signed device-membership history before accepting changes.
A device remembers the last history checkpoint it accepted. It rejects rollback and stops when it encounters a conflicting branch. The server can't add a device on its own. Tailscale carries traffic, but envden doesn't use Tailscale identity headers to authorize requests.
Checkouts need your approval
A folder doesn't receive secrets just because its git remote matches a repo. You approve each checkout in your terminal, including every new worktree. Approval lives outside the checkout, and --yes doesn't bypass it.
Pulled paths are checked for traversal and symlinks escaping the checkout. Placement uses directory handles on macOS and Linux when FFI is available.
Protect your password and recovery kit
The master password and a random secret key protect the recovery envelope. Argon2id derives password material; the random secret key is printed in your kit and isn't saved on devices. Recovery requires both. Password login uses OPAQUE.
Keep the kit somewhere safe and separate from your devices. Writing the password on it makes the kit sufficient to open the vault. See device and recovery commands.
Device keys use the OS keychain adapter, with a 0600 file fallback where needed. Local store files use 0600 permissions and directories use 0700, with ACLs on Windows.
What envden can't protect against
- A compromised member device can read the files and keys it has access to. Removing it doesn't erase downloaded files or prevent decryption of older ciphertext with keys it kept. Rotate exposed credentials after removal.
- Files already on disk depend on your OS login and disk encryption. Unlock expiry only limits new server access, and a malicious server can ignore it. A stolen laptop hosting the server can bypass expiry too.
- The server can deny service or show devices separate branches of history. A device stops when it sees the other branch. A server colluding with a removed device or an old recovery key can fork history.
- Encryption doesn't hide rough file sizes, timing, device count or device names from the server.
- A stolen server password record permits offline password guessing. A correct guess still needs the kit's secret key to open the recovery envelope. Protect server backups like a password database.
- On Windows, or when FFI is unavailable, a local process can race a parent-directory replacement after the final path check.
Cryptographic implementation
The protocol uses pinned versions of @noble/ciphers, @noble/curves, @noble/hashes, hash-wasm, @serenity-kit/opaque and @hpke/*. envden's protocol combines these primitives; its encodings and test vectors are in PROTOCOL.md.
The threat model describes the trust assumptions behind these protections.