The case for Vaultaire

Privacy apps have a fatal flaw: they look like privacy apps.

A locked folder announces it's locked. A hidden gallery called “Calculator+” fools no one who's looking. Every “secure” photo vault on your iPhone shares the same problem: it proves you have something to hide.

When someone forces you to unlock your phone, whether that's a border agent, an abusive partner, or an authoritarian government, they see the app, they see the lock, and they don't stop until you open it.

Vaultaire does not open to a catalog of named vaults. A pattern addresses one encrypted vault, and the interface does not advertise the others.

How encrypted photo storage should actually work

Draw a pattern on the grid. PBKDF2 derives a local vault key, which authenticates the encrypted index and unwraps the random master key used for AES-256-GCM file encryption. Draw a different configured pattern, and a different encrypted vault can open. AES operations run in the app process through CryptoKit; Vaultaire does not claim arbitrary symmetric encryption inside Secure Enclave.

Enter a pattern with no matching index? No “incorrect password” message and no list of other vaults, just an empty creation state. That equivalence applies to the interface. A copied index filename and AES-GCM tag still let a filesystem attacker verify guesses offline.

The interface shows no cross-vault list, but the storage boundary is explicit: each local vault has an enumerable encrypted index file, and storage usage changes with encrypted content. A filesystem examiner may count indexes and copy ciphertext, while the pattern-derived key and random master key protect the readable file map and contents.

This is not a lock on a door. It's a wall where the door used to be.

Why zero-knowledge architecture matters

A lock screen alone does not prove that files are encrypted. Any photo vault should be judged by its storage format, key hierarchy, recovery path, and behavior when the app container is copied, not by the presence of a PIN or pattern screen.

Vaultaire was built around a narrower principle: services that store encrypted Vaultaire records should not receive readable vault contents or decryption keys. The client, iOS, Keychain, and the unlocked device remain part of the trust model, and encrypted files remain detectable as encrypted application data.

No Vaultaire identity account. The app does not require your email address or phone number. Apple can still hold purchase, iCloud, and device-account records, and consent-based analytics can create pseudonymous product events under the privacy policy.

No cloud dependency for local vault use. Vaultaire creates CloudKit records only when you choose encrypted backup, device sync, or sharing; CloudKit then receives ciphertext and operational metadata, not readable vault files or plaintext decryption keys. iCloud Backup and computer device backups are separate system paths and may include the app’s encrypted local files.

No biometric unlock inside Vaultaire. A pattern provides a credential separate from the iPhone passcode and Face ID, but it can still be observed, guessed, disclosed under coercion, or captured on a compromised device. We left biometrics out to keep that access path explicit.

No email reset. No provider-held recovery key. Vaultaire generates a custom nine-word recovery phrase, not a BIP-39 mnemonic. It stores the phrase in an encrypted Keychain database so you can view it later, and it can store a phrase-encrypted CloudKit manifest when backup is enabled.

Your pattern goes through 600,000 rounds of PBKDF2-HMAC-SHA512 with a device-wide salt to derive a 256-bit vault key. That output length does not turn a guessable pattern into 256 bits of entropy. The key exists in app memory during use, and lock paths discard active state without claiming a provable wipe of every transient copy.

Who it's for

Journalists protecting sources where phone searches are routine. Activists carrying documentation under government surveillance. Domestic abuse survivors keeping evidence secure on a device they know is being monitored. Travelers crossing borders where device inspection is mandatory. Attorneys with privileged materials on personal phones.

And anyone who gets that privacy isn't about having something to hide. It's about having something worth protecting.

The duress vault

Designate any vault as a duress trigger. When that pattern is drawn, the designated vault opens while Vaultaire removes other local indexes and recovery mappings from the current device. Existing encrypted iCloud backups and peer-device copies remain unchanged, and later recovery requires an explicit recovery phrase.

The flow is silent in the app interface, not guaranteed undetectable under forensic analysis. Deleted files, filesystem state, cloud records, peer devices, or a previously compromised device may still reveal that data existed or changed.

What we won't build

We won't add biometric unlock, because it can be legally compelled. We won't add cloud-dependent storage, because it creates a target for subpoenas and breaches. We won't add analytics that track how you use the app. We won't add a backdoor dressed up as account recovery. We won't weaken the architecture for convenience.

Every decision in Vaultaire comes back to one thing: your private files stay yours, under any circumstance.