NullVault separates a random vault master key from the pattern a person remembers. The pattern is processed by a deliberately expensive key-derivation step and used to unlock the matching encrypted vault state; content is protected with authenticated encryption. Platform key protection, encrypted metadata, and fail-closed parsing add layers, but none of them can protect plaintext after a compromised operating system observes a successful unlock.
Release status: NullVault is available on iPhone and Android.
From a pattern to a vault
The pattern is not the vault's permanent content-encryption key. Instead, the high-level flow is:
- NullVault converts the ordered points in the pattern into a canonical byte sequence.
- A memory-hard password function derives candidate access material using installation-specific context.
- Platform-protected key material is applied where the platform design requires it.
- NullVault tests the fixed-shape authenticated access records without first consulting a visible vault index.
- A successful authenticated result unwraps the random key for that vault.
- Separate derived keys protect headers, metadata, and content records.
This separation lets a pattern change rewrap access to a stable vault key instead of re-encrypting every item. It also means a pattern should be treated like a password: familiar shapes and short gestures are easier to guess.
See pattern-locked vaults for the user-facing explanation.
Authenticated encryption
NullVault uses authenticated encryption for its managed content. Encryption provides confidentiality; authentication detects modifications before plaintext is accepted. Files are divided into independently authenticated records or chunks, while metadata and access state use separate authenticated domains.
The design avoids one shared content key for every file. A vault master key anchors the vault, and domain-separated or per-file keys reduce unintended key reuse. Persistent formats carry explicit versions and strict parsers so unknown or malformed records fail closed.
Encryption does not conceal every observable fact. Ciphertext length, allocation changes, file counts, access timing, and cloud operations may expose activity even when filenames and content remain encrypted.
Hidden-vault discovery
NullVault does not present a master list from which a person chooses a vault. An entered pattern attempts to open its matching authenticated access record. Existing vaults remain available only through their patterns, while an acceptable new pattern can create a separate vault when creation is available.
The security claim is deliberately narrow. “No visible master list” is not the same as “no forensic trace.” A live compromised process, app-container history, repeated snapshots, quota behavior, or platform metadata can reveal information that an ordinary locked-app view does not.
Learn more about pattern-addressed hidden vaults and the documented limitations.
Android trust boundaries
The released Android design combines:
- AES-256-GCM authenticated encryption for protected vault data;
- memory-hard Argon2id key derivation for pattern-derived work;
- device-protected Android Keystore key material;
- encrypted filenames, metadata, thumbnails, and file contents in private app storage;
- explicit, user-controlled portable encrypted backup.
The pattern itself is not uploaded or stored as recoverable text by NullVault. A copied encrypted container is not sufficient for ordinary local access when its required device key is unavailable, but this does not protect against an attacker controlling the running app or operating system during unlock.
Android device recovery and portable recovery are separate. The device-recovery phrase can replace a forgotten pattern while the vault remains on the original device. Portable backup uses a separate backup recovery phrase and requires the valid encrypted backup file.
iOS trust boundaries
The released iOS design combines AES-256-GCM authenticated encryption, memory-hard Argon2id pattern processing, Apple CryptoKit, and libsodium with encrypted private app storage. Each vault has its own 24-word BIP-39 recovery phrase. Local use does not require a NullVault account.
Encrypted backup is created on the device before being stored in the user's iCloud account. Sharing creates a separate encrypted, read-only replica controlled by its own 24-word sharing phrase, expiration, revocation, and owner export policy. These controls do not erase prior exports, screenshots, photographs, or copies retained outside the supported flow.
Recovery and encrypted backup
A recovery credential and a backup solve different problems.
- Local recovery changes or restores access to encrypted state that is still present and valid on the device.
- Backup recovery needs both authority from the recovery secret and the encrypted backup objects containing the data.
On Android, same-device recovery can replace a forgotten pattern while the local encrypted state remains available. Restoring elsewhere requires a portable encrypted backup and its separate backup recovery phrase.
On iOS, the vault's 24-word recovery phrase authorizes recovery and encrypted iCloud backup restore. The phrase does not recreate missing ciphertext, and NullVault cannot recover it from an account or server-side master key.
Read recovery phrase versus encrypted backup before relying on either.
Locking and plaintext lifetime
When NullVault locks, it revokes app-level access to active keys and should remove derived material from managed memory as far as the platform permits. The app also avoids persistent plaintext temporary files for its managed content paths.
Memory clearing is best-effort on managed runtimes and modern operating systems. The system, a debugger, malicious code, or a compromised kernel may have copied plaintext or key material while it was in use. Locking protects future ordinary access; it cannot recall data already observed.
Questions people ask
Is the pattern stored on disk?
The design does not persist the pattern as recoverable text or a reusable hint. It processes the entered gesture to attempt authenticated access. Weak, observed, or reused patterns can still be guessed.
Why use a random vault key as well as a pattern?
A random vault key gives content stable high-entropy protection. The pattern controls a wrapping layer, so changing the pattern does not require every item to be encrypted again.
Is encrypted cloud storage the same as no cloud metadata?
No. NullVault is designed to send encrypted application payloads, but the provider can still process account, timing, size, record, device, and network metadata needed to operate the service.
Can a recovery phrase recreate files by itself?
Only when the relevant recovery design says so and the required encrypted material still exists. Android portable recovery requires the valid encrypted backup file and its separate backup phrase. iOS restore requires available encrypted iCloud backup state and the vault's recovery phrase.
Is the architecture a guarantee against forensic analysis?
No. The model describes scoped protections for encrypted content and vault discovery. It does not claim to defeat every forensic technique, repeated snapshot, compromised platform, or observation made while a vault is open.
Architecture content reviewed: 1 September 2026.