Security overview

How VaultBe keeps your vault closed

This page describes the design in plain terms, names the algorithms, and is equally clear about the limits. If a claim here matters to you, it should be specific enough to check.

The short version

  • Everything in a vault is encrypted with AES-256-GCM: files, thumbnails, names, folders and dates.
  • The key comes from your pattern, stretched with Argon2id. The pattern is never stored.
  • On your device, the key is also bound to a secret in the iPhone Keychain that never leaves it.
  • Backups and sync go to your own iCloud as padded ciphertext.
  • There is no account, no server of ours that sees your data, and no analytics.

Key hierarchy

Each vault has a random 256-bit master key, generated on your device. The master key is never stored in the clear. It is wrapped (encrypted) separately for each way of opening the vault:

WrapDerived fromUsed for
LocalPattern → Argon2id, mixed with the device secret via HKDFUnlocking on this device
CloudPattern → Argon2id → HKDF with the vault's saltRestoring a backup on any device
RecoveryRecovery phrase → Argon2id → HKDFGetting in when the pattern is forgotten

From the master key, HKDF-SHA256 derives independent sub-keys for the index, for wrapping per-file keys, for backup record names and for sync. A weakness in one use cannot spill into another.

Key derivation

Patterns and phrases are low-entropy compared with random keys, so VaultBe makes each guess expensive. Argon2id is run with 128 MiB of memory and 6 passes. Memory-hardness matters because it stops attackers from cheaply parallelising guesses on graphics cards or custom chips.

Wrapped keys are also bound, as authenticated data, to their role and the vault's salt. A wrap copied from one place cannot be replayed in another.

File encryption

  • Each file has its own random key, wrapped under the vault's file-wrap key.
  • Content is encrypted in 1 MiB chunks with AES-256-GCM. Each chunk is authenticated, so tampering or truncation is detected, and large videos can be played without decrypting the whole file.
  • Encrypted files are padded (using the PADMÉ scheme) so their size leaks very little about the original, at a cost of at most about 12%.
  • On disk, files have random names. Real names, folders, dates and thumbnails live only inside the encrypted index.

Device binding and guess limits

The local wrap mixes in a random secret stored in the Keychain as a this-device-only item. Someone who copies VaultBe's files off your phone, for example from a computer backup, cannot test patterns against them elsewhere, because that secret did not come along.

On the device, wrong patterns are throttled: four free attempts, then a delay that starts at 30 seconds and doubles up to one hour. The throttle state is kept in the Keychain so it survives restarts.

Keys in memory

While a vault is open, key material is held in dedicated buffers that are zeroed when released. Locking the vault, leaving the app or reaching the auto-lock timeout discards them. Temporary files created during import or playback are stored with iOS data protection and removed afterwards.

iCloud backup, sync and sharing

VaultBe uses Apple's CloudKit as a blind store. It uploads the same encrypted, padded blobs that are on disk, plus an encrypted index and a vault header carrying the cloud wrap. Records are named with an HMAC under the vault's backup key, so records from different vaults cannot be linked and nothing describes their contents.

Shares work the same way: the ten-word share phrase derives both the location of the share and the key that decrypts it. The relay holds ciphertext only.

A trade-off to know about. A backup must be restorable on a new device, so it cannot depend on the old device's Keychain secret. In iCloud, your vault is protected by the Argon2id-stretched pattern alone. Use a longer pattern if you turn backup on.

Duress Mode

The duress pattern performs crypto-shredding: it deletes the headers that hold the wrapped master keys of every other vault, then their indexes, files and iCloud records. Without a wrapped master key, the remaining ciphertext cannot be decrypted by anyone.

What VaultBe does not protect against

No app can honestly claim to cover everything. VaultBe does not protect you from:

  • Someone who knows your pattern or recovery phrase, or who watches you draw it.
  • A compromised device. Malware or a jailbreak that can read another app's memory can read an open vault.
  • An open vault in someone else's hands. Auto-lock narrows that window; it cannot close it.
  • Screenshots. iOS does not let apps block them. VaultBe hides content during recording and logs screenshots.
  • Proof of absence. A forensic examiner may be able to tell that the app holds encrypted data, and roughly how much, even though they cannot read it.
  • A weak pattern on a backed-up vault, if an attacker gains access to your iCloud account.

What we collect

Nothing from the app. There is no account, no analytics SDK, no advertising SDK and no third-party crash reporter. See the Privacy Policy.

Reporting a vulnerability

If you believe you have found a security issue, please write to support@vaultbe.app or use the support form with the topic "Security report". We will reply, and we will credit you if you wish.

Keep it private. Keep it yours.

Draw a pattern and your first vault is ready in under a minute. No account, no email, nothing to sign up for.

Coming soon to the App Store Explore features