Security

Built like a safe, not a service

Your data is sealed by a memory-hard key derivation function, encrypted with AES-256-GCM, and bound to your phone's secure hardware. There are no servers in the loop — and we will be honest about what that does and doesn't protect.

256-bitAES-GCM encryption
64 MiBArgon2id memory cost
0servers, accounts or trackers
5failed tries to crypto-erase
A — Encryption pipeline

From passphrase to ciphertext

Your passphrase is never stored and never used directly as a key. It is stretched through Argon2id and used only to unlock a separate, random key that actually protects your data.

  • Your passphrase runs through Argon2id at a 64 MiB, memory-hard setting, deriving a key-encryption key (KEK).
  • The KEK unwraps a random AES-256 data-encryption key (DEK) — the key the vault is actually built on.
  • The DEK encrypts your vault with AES-256-GCM and protects the metadata database with SQLCipher.
  • Changing your passphrase only re-wraps the DEK — it never re-encrypts the whole vault, so it's instant.
1

Passphrase → Argon2id

Memory-hard stretching turns a typed phrase into a strong key-encryption key.

2

KEK unwraps the DEK

The derived key unlocks a random AES-256 data key — never the data itself.

3

DEK encrypts everything

AES-256-GCM seals files; SQLCipher seals the database that indexes them.

B — Plausible deniability

A hidden vault that can't be proven to exist

Some situations call for more than a strong password. OmniVault can hold a hidden volume inside the same container — and there is no header, flag, or signature that reveals it is there.

  • The container uses fixed-size slots with no plaintext header — the bytes look the same whether a hidden vault exists or not.
  • A wrong passphrase and an empty slot fail in exactly the same way — there's nothing to tell them apart.
  • Unlock the decoy passphrase under pressure and you reveal a believable, ordinary vault — and nothing more.

The result: no one can prove a hidden vault is present. Deniability is built into the format, not bolted on after the fact.

Fixed-size slots

Uniform blocks reveal no clue about how much — or how little — is stored.

No plaintext header

Nothing in the file announces its structure or that a second vault exists.

C — Hardware binding

Sealed to this phone, gated by your fingerprint

A strong passphrase protects the data; the secure hardware on your device protects the data at rest. Even a perfect copy of the file is useless without the chip it was sealed on.

  • At rest, the container is wrapped by a key held in StrongBox / the secure enclave — gated by your fingerprint.
  • That hardware key never leaves the chip, so the file can't be brute-forced on another machine.
  • Five failed attempts trigger a crypto-erase — the hardware key is destroyed and the vault becomes unrecoverable.

Key on the chip, not on disk

The wrapping key lives in tamper-resistant hardware and is released only after a successful biometric check on this device. Lift the file off the phone and there is no key to go with it.

Crypto-erase means there's no slow lockout to wait out — after five misses, the key is simply gone.

D — Zero-knowledge & offline

Nothing to breach, subpoena, or leak

The strongest way to protect data from a server is to never put it on one. OmniVault has no backend at all — your vault lives only on your device.

  • No servers and no accounts — there is no copy of your data anywhere but in your hand.
  • No network permission — the app simply cannot send your data off the device.
  • No analytics or telemetry — nothing is measured, logged remotely, or phoned home.

No backend

There is no database for an attacker to compromise or a court to compel.

No network access

Without the permission, there is no path for data to leave the phone.

E — Threat model

What we defend against — and where we're honest

No app can promise total security. Here is a clear picture of what OmniVault is designed to stop, and the limits no software can fully solve.

Designed to defend against

  • A lost or seized phone. The vault is encrypted at rest and bound to secure hardware; the file alone reveals nothing.
  • Coercion. A decoy vault and a panic action let you hand over a believable, ordinary vault without exposing the hidden one.
  • Shoulder-surfing. Sensitive content stays sealed until you unlock it, and the hidden vault leaves no visible trace on screen.
  • Offline brute-force. A memory-hard KDF plus a hardware-bound key make guessing your passphrase on a separate machine impractical.

Honest limits

Some threats live below or beyond what any vault app can address. We would rather say so plainly than overclaim:

  • A rooted or compromised operating system. If the platform itself is subverted, the protections it provides — including secure hardware and the screen — can no longer be fully trusted.
  • Malware that can screen-capture while the vault is open. Once you've unlocked and are viewing content, software with sufficient access could observe what's on screen.
  • Coercion that goes beyond a decoy. Plausible deniability helps when a believable cover vault is enough; it cannot solve every real-world situation involving physical pressure.

Strong defaults reduce these risks, but they are properties of the device and the world — not problems an app can promise to eliminate.

F — What we don't do

By design, never

Some of the strongest privacy guarantees are the things we simply refuse to build.

No cloud

Your vault never syncs to a server or anyone else's storage.

No tracking

No analytics, no device fingerprinting, no behavior logging.

No ads

Nothing in the app is funded by selling your attention.

No data sale

There's no data collected, so there's nothing to package or sell.

No backdoors

No master key and no recovery path that bypasses your passphrase.

No exceptions

These rules don't change for "trusted partners" — there aren't any.

Read it, then judge it

See how the pieces fit together end to end, or check our privacy stance line by line.