Security

Everything we claim, in one place.

You shouldn't have to take our word for any of it. This page names the libraries, links the audits, publishes the file format, and says plainly what we can't protect you from.

What is audited, and what isn't

• Audited: the secret-sharing library, shamir-secret-sharing (Privy). Independently audited by Cure53 and by Zellic. We use it unmodified.
• Not yet audited: this application, which composes that library with the browser's built-in AES-GCM and HKDF (Web Crypto) and an Argon2id implementation (hash-wasm). The design uses only standard primitives, but a third-party review of the app has not happened yet. We'll publish it here when it does. Until then, treat Zero-Trust Vault as beta software and keep a backup of anything critical.

Verify the offline app

Every visit to a website loads fresh code from its server. That is true of every web app, including ours: if our hosting were ever compromised, it could serve modified code. If that risk matters to you, don't use the website to seal anything important. Download the offline file, check its fingerprint, and seal with that.

This is the SHA-256 of the offline app currently served at /app/zero-trust-vault (version 3.0.0, 902 KB):

d9468f13b5547108333adeadd002183b56352db3311e857bd3d256aa9c8d0677

To check your copy, run shasum -a 256 zero-trust-vault.html (macOS, Linux) or certutil -hashfile zero-trust-vault.html SHA256 (Windows) and compare. A plain-text copy is at /app/zero-trust-vault.sha256.

Honest limit: this page and the file come from the same server, so the fingerprint catches corruption and mistakes, not a compromised server. The strong version of this check is to download the file once, keep it, and compare later downloads against your kept copy or against fingerprints other people have recorded.

File format (v3)

A .vault file is JSON. A random 256-bit data key encrypts the contents with AES-256-GCM. Each way of unlocking is a separate "slot" that wraps that data key under its own key-encryption key (derived with HKDF-SHA256). The header, including every slot, is authenticated as AES-GCM associated data, so changing any byte makes decryption fail.

• Shards: Shamir secret sharing over GF(2⁸) of a 32-byte secret, with any k of n needed (2 ≤ k ≤ n ≤ 16). Fewer than k shards reveal nothing. A shard is ztv2.<vault id>.<index>.<k>.<n>.<fingerprint>.<share>.<checksum>.
• Passphrase: Argon2id, 256 MiB / 2 passes (64 MiB / 3 passes where the device can't allocate more). Parameters are stored in the header and bounds-checked on read.
• Both together: the key-encryption key is derived from the Shamir secret and the passphrase output, so neither alone opens the vault.
• Passkey: the WebAuthn PRF extension derives a secret inside the authenticator, with a per-vault salt.
• Key commitment (v3): the header carries HMAC-SHA256(dataKey, vault id). Every unwrapped key must match it, so a maliciously crafted vault can't show different people different contents.
• Shard commitments (v3): the header carries a 128-bit hash of every shard, so a forged shard is named even when exactly k shards are presented. Hash-based, so it stays safe against quantum computers.
• Size hiding: contents are padded with Padmé padding, and file name and type are encrypted along with the data.
• No public-key cryptography appears anywhere in the format.
• Older vaults: v2 vaults (same design without the two commitments) still open, and a real v2 vault is opened by our automated tests on every build.

What we can see

Encryption happens on your device before anything is stored. Our servers only ever hold locked files. The vault's id, creation time, optional label, which unlock methods exist, and approximate size are visible to whoever holds the file. The label is not encrypted, so never write what is inside it ("Binance seed" tells a thief exactly what to look for). If you use Legacy, we also hold your trustees' names and emails, your message to them, and at most one escrowed shard, which on its own opens nothing.

What this does not protect against

• A compromised device or browser: malware, a malicious extension with page access, or a keylogger sees what you see.
• Modified code served by a compromised website (see "Verify the offline app" above).
• Losing more shards than you can spare, or forgetting your passphrase. There is no recovery and no backdoor, by design.
• Memory forensics. JavaScript can't guarantee that secrets are wiped from RAM. Decrypted contents clear automatically after five minutes.
• Legacy delivery if our service is not running on release day. Your vaults never depend on us, but Legacy's automatic emails do. Keep a printed recovery kit and the offline file with the people who matter as a fallback.

Not legal advice

Zero-Trust Vault is a technical tool. It is not a will and does not give anyone legal authority. Whether a trustee may lawfully access an account or a crypto holding after your death depends on where you live, and exchange terms of service often forbid sharing credentials. Talk to a lawyer about your estate plan, and use this to make the technical side reliable.

Source code

The whole application is open source under the AGPL-3.0: github.com/shrestha-droid/zero-trust-vault-v2. Read it, build it yourself with npm run build, and compare how it behaves. The test suite, including the attacker scenarios, runs in public on every change. Byte-for-byte reproducible builds (so you could prove the offline file above matches the source) are not guaranteed yet.

Report a vulnerability

Use the private "Report a vulnerability" form on GitHub (it is visible only to the maintainer). Please include steps to reproduce and the version shown in the app's header, and don't disclose publicly until we've had a chance to fix it.