This page is deliberately specific. A vault that waves a marketing phrase at you and stops there is asking you to take its word for it. Below is what Weave Vault encrypts, what it derives keys from, and what leaves your device and when.

What is encrypted

Everything the app stores, not just the files. Each of the following is sealed with AES-256-GCM before it is written to disk, with a fresh random 96-bit nonce per seal and a 128-bit authentication tag:

• Photos, videos, documents, and any other file you import.
• Generated thumbnails.
• Item metadata — including the filename, size, media type, and date added.
• The vault manifest that lists what a vault contains.
• The key-wrapping headers themselves.

Filenames and metadata are the part most vaults leave readable. A directory listing that shows passport-scan.pdf has told the story before anyone opens anything, so none of it is stored in the clear. What the file system shows instead is a set of randomly named files and their byte counts — nothing that hints at what any of them holds.

How the keys work

The chain from your finger to your files has four links.

1 · Your pattern

Canonicalised into bytes. It is never stored — not in a file, not in the keychain, and not as a hash. It exists in memory only for as long as the derivation takes.

2 · Argon2id

The pattern is stretched into a 256-bit key-encryption key with Argon2id (RFC 9106) at t=3, m=64 MiB, p=1, over a random 128-bit salt stored per vault. That memory cost is the defence against GPU-scale attacks, and the reason Argon2id won the Password Hashing Competition and is OWASP’s first recommendation for this job.

3 · The vault key

Each vault has its own 256-bit key, generated from the system CSRNG at creation and never derived from anything you typed. The pattern-derived key wraps it. Your recovery phrase derives a second key that wraps the same vault key independently — which is why either one opens the vault, and why losing both is final.

4 · Per-item subkeys

Every item gets its own key via HKDF-SHA256 (RFC 5869) from the vault key, domain-separated by purpose — one domain for file contents, one for metadata, one for thumbnails. No two items share key material.

Large files

Files up to 64 MB are sealed as a single blob. Above that, they are encrypted in 4 MB chunks and streamed, so a 12 GB video never needs to be held in memory. Each chunk is authenticated against its own absolute index, which means a chunk cannot be swapped with another, reordered, duplicated, or the file truncated, without decryption failing outright rather than quietly returning a shorter file. The ceiling is 16 GB per file.

The recovery phrase

Twelve words drawn from the standard BIP-39 English word list — 128 bits of entropy plus a checksum, the same construction used by self-custodial cryptocurrency wallets. It is displayed exactly once, when a vault is created, and it is never transmitted or stored anywhere we can reach. You can replace a vault’s phrase at any time from its settings, which immediately retires the old one.

What the app deliberately does not do

• It does not tell you that a pattern was wrong. There is no stored value to compare against, so an unrecognised pattern is indistinguishable from a new one — the app opens an empty vault either way. This is a property of the design, not a message we chose to hide.
• It does not count your vaults back at you. No screen displays how many vaults exist on the device.
• It does not collect anything. No analytics, no crash reporting, no advertising or attribution SDKs, no device fingerprint.
• It does not ride along in your device backup. Vault storage is excluded from the ordinary iCloud/Finder backup on iOS, and from Android’s cloud backup and device-transfer paths.

When the app locks

An open vault closes and its keys are cleared from memory when you leave the app, when the device locks, after two minutes without interaction, when the operating system reports a screenshot or screen recording, and when the system withdraws access to protected storage. On iOS a screen recording replaces the content with a blocked surface; on Android the window is marked secure in release builds, so the system declines to capture it at all.

When data leaves your device

By default, never — with every optional feature off, the app makes no network requests. Two features change that, and both are opt-in.

Encrypted backup

Backup copies the vault storage to your iCloud private database on iPhone and iPad, or your Google Drive hidden app folder on Android. What is uploaded is the same ciphertext that sits on your phone — no vault key and no plaintext ever leaves the device, which is also why a backup can run while the app is locked. Apple and Google hold bytes they cannot read; we hold nothing at all, because there is no account tying them to you. Backup uploads the whole storage pool rather than only the vaults in use, so the upload does not reveal how many vaults you keep.

Sharing

Creating a share uploads a re-encrypted, point-in-time copy of a vault and gives you a one-time phrase to pass to the recipient. The key is split in two: one half derives from the phrase and never touches a server, and the other half is held by a small gate service we run. Both halves are required to decrypt anything, which is what makes expiry and revocation enforceable rather than advisory — the gate can refuse.

That gate is the one place Weave Vault records anything server-side. For each share it holds an identifier, the expiry you chose, and a revocation flag — never your files, never your phrase, and nothing that identifies you. The privacy policy lists everything it stores. Shares expire after at most 30 days and are swept automatically.

Duress mode

Duress mode is optional and off until you arm it. You nominate a second pattern belonging to a decoy vault. Drawing that pattern opens the decoy normally — and in the same moment, this device discards its keys to every other vault on it.

What that does. Each vault’s key is wrapped twice, once by the pattern and once by the recovery phrase, and both wrappings live in the same header. Duress overwrites that header, so both routes in close together. The vault’s files stay exactly where they were on disk — they are simply ciphertext that no longer has a key on this device.

What it is not. This is a device discarding keys, not a shredder and not a forensic wipe. We make no claim about what an examiner with the physical device could or could not determine, and you should treat any product that does make that claim with suspicion.

Your backup is the way back. If encrypted backup is on when duress fires, the backup is frozen, never deleted — syncing stops so the emptied device cannot overwrite it, and the copy already stored stays restorable. If backup was off, those vaults are gone from that phone for good, and the recovery phrase will not bring them back, because it was wrapped in the same header.

Because of that, arming is deliberately harder than a toggle. It happens inside the decoy vault’s own settings, confirmed by re-drawing that vault’s pattern, and if you have no backup the app states plainly that the recovery phrase will not help and asks you to type a confirmation. A restore onto a new device, or a device-to-device transfer, disarms it automatically.

Reporting a vulnerability

If you think you have found a security issue, email [email protected]. Tell us what you found and how to reproduce it, and please give us a reasonable window to fix it before publishing. We will credit you if you would like us to.