Security Architecture: The Full Technical Stack

Vaultaire uses AES-256-GCM for authenticated encryption across vault indexes, wrapped keys, file headers, content, thumbnails, and metadata. PBKDF2-HMAC-SHA512 derives a local vault key from the pattern and a device-wide Keychain salt. That vault key wraps a separate random 256-bit master key, which performs the file encryption through CryptoKit in the app process.

The Cryptographic Stack

Vaultaire uses several cryptographic mechanisms working in concert, each chosen for a specific job. PBKDF2 turns a human credential into a vault or recovery key. AES-256-GCM protects indexes, wrappers, metadata, thumbnails, and file content. A random master key separates long-lived file encryption from a changeable pattern. Keychain and iOS Data Protection protect device-bound salt and recovery records while the device is locked. No provider-held decryption key gives the developer routine access to vault plaintext.

This is not complexity for its own sake. Each layer addresses a different attack surface. AES-256-GCM combines confidentiality with authentication, so modified ciphertext fails verification. PBKDF2 raises the cost of testing each pattern or phrase. The random master key means a pattern change can rewrap one key instead of re-encrypting every file. Keychain data protection guards local salt and recovery records, while the app still acknowledges that symmetric encryption happens in process memory.

Together, these layers form a defense-in-depth architecture, but they are not all independent barriers. A guessed pattern can be checked against the index filename and AES-GCM authentication, and a compromised unlocked device can observe keys or plaintext in the app process. The architecture therefore depends on credential entropy, PBKDF2 cost, iOS device protection, and correct authenticated-encryption handling as well as the strength of AES itself.

AES-256-GCM: File Encryption

Every photo, video, and document stored in Vaultaire is encrypted with AES-256-GCM — the Advanced Encryption Standard with a 256-bit key in Galois/Counter Mode. Vaultaire also uses AES-GCM for vault indexes, file headers, thumbnails, and key envelopes. The algorithm and key size are standardized; Vaultaire’s security still depends on nonce handling, key management, credential strength, and implementation correctness.

The “256” in AES-256 refers to the key length in bits. A 256-bit key has 2²⁵⁶ possible values. To put that number in perspective: there are roughly 10⁸⁰ atoms in the observable universe. If every atom were a supercomputer testing a billion keys per second, running since the Big Bang, they would have explored less than a trillionth of a trillionth of one percent of the key space. AES-256 is not going to be brute-forced. Not today. Not this century. Not before the stars burn out.

Why GCM Mode Matters

AES is a block cipher — it encrypts data in 128-bit chunks. The “mode” determines how those chunks are combined. GCM (Galois/Counter Mode) provides two things that simpler modes like CBC do not: parallelized encryption and built-in authentication.

The authentication piece is critical. GCM generates a cryptographic tag for every encrypted file. This tag acts as a tamper seal. If even a single bit of the ciphertext is modified — whether by a malicious actor or a corrupted disk sector — the authentication tag will not match, and decryption will fail. You do not get corrupted data. You get a clear signal that something is wrong. This property is called authenticated encryption, and it prevents an entire class of attacks where an adversary modifies encrypted data to manipulate the decrypted output.

PBKDF2: Key Derivation

Vaultaire derives different keys for different jobs. The pattern and a device-wide Keychain salt feed PBKDF2-HMAC-SHA512 for 600,000 iterations to produce the local vault key. A deterministic pattern derivation produces the separate cloud backup key. The normalized recovery phrase runs through 800,000 PBKDF2 iterations to produce the key for a recovery envelope. None of those derivations turns a human credential into 256 bits of entropy merely because the output is 256 bits long.

How PBKDF2 Protects Your Pattern

The core idea behind PBKDF2 is deliberate work. It takes the serialized pattern or normalized phrase and runs hundreds of thousands of HMAC-SHA512 iterations. A legitimate user pays that cost once during an unlock or recovery attempt. An attacker pays it for every candidate, although parallel hardware and implementation choices determine the real guessing rate.

Vaultaire configures PBKDF2 with 600,000 iterations for pattern-derived keys. That makes each guess more expensive, but a responsible attack estimate must state a measured per-candidate time and hardware assumptions. At exactly one millisecond per candidate, one billion serial guesses take about 11.6 days, not years. The 256-bit result does not expand the entropy of a predictable pattern.

Local pattern derivation uses one cryptographically random salt for the device, stored as a WhenUnlockedThisDeviceOnly Keychain item. The salt is not secret and is shared by the vaults on that device. It prevents a table built for one device from applying directly to another device with a different salt, but it does not force an attacker to start over for every vault on the same device.

AES-256-GCM: Metadata Protection

Encrypting file contents is not enough. File names, creation dates, thumbnail dimensions, and vault structure are all metadata — and metadata can be just as revealing as the data itself. A file named “tax-return-2025.pdf” tells an attacker exactly what is inside even if the contents are encrypted. A timestamp shows when you used the vault. A thumbnail size reveals whether something is a photo or a video.

Vaultaire protects this metadata with AES-256-GCM, not ChaCha20. File names and MIME types are encoded into encrypted file headers. The encrypted vault index contains file records, dates, size information, storage layout, and the wrapped master key. Thumbnail data is also encrypted under the random master key.

Why Authenticated Encryption for Metadata?

Metadata needs integrity as well as confidentiality. AES-GCM produces an authentication tag for each encrypted value, so Vaultaire can reject a modified header, index, thumbnail, or envelope instead of accepting attacker-controlled plaintext. The design deliberately uses one authenticated-encryption construction across these storage formats rather than claiming cryptographic diversity that the implementation does not provide.

The same cipher does not mean the same key or nonce is reused blindly. The vault key protects the index and wraps the random master key; the master key protects file material. CryptoKit creates authenticated sealed boxes with fresh nonces, while Vaultaire’s streaming format derives a distinct nonce for each ordered chunk. The relevant guarantees come from key separation, nonce discipline, and authentication, not from a second metadata cipher.

Zero-Knowledge Architecture

Here is a question worth asking about any security app: what happens if the company behind it gets hacked, subpoenaed, or simply turns malicious?

With most apps, the answer is uncomfortable. They hold your data, your keys, or both. A court order compels them to hand it over. A data breach exposes it. A rogue employee accesses it. The app’s security is only as strong as the company’s operational security — and history shows that companies get breached regularly.

Vaultaire does not operate an account or storage service that receives your pattern, secret phrase, decryption keys, or readable vault contents. Encryption and decryption happen in the app process on your device. When iCloud backup is enabled, the app sends authenticated ciphertext to your private CloudKit database rather than to a Vaultaire-controlled vault service.

What Zero-Knowledge Means in Practice

If a law enforcement agency serves Vaultaire with a subpoena demanding vault plaintext, the company does not hold the pattern, recovery phrase, vault key, backup key, or master key needed to decrypt it. Encrypted iCloud records live in the user’s CloudKit private database. On the device, however, recovery material is held in an encrypted Keychain database, and symmetric keys exist in app memory while CryptoKit encrypts or decrypts an open vault.

This provider boundary is an architectural property, not a promise that every part of the client environment is outside the trust model. Vaultaire does not hold a server-side decryption key it can surrender for routine vault recovery. The shipped app, iOS, the unlocked device, and the cryptographic implementation can still process readable data and must be trusted accordingly.

Keychain and the App-Process Boundary

Apple’s Secure Enclave can protect supported private keys and participates in parts of the platform security architecture, but its public APIs do not accept an arbitrary PBKDF2-derived symmetric key and perform Vaultaire’s AES-GCM file operations inside the coprocessor. Vaultaire therefore does not describe its vault cipher as Secure Enclave AES.

Vaultaire uses ordinary iOS Keychain generic-password items for the random device salt, encrypted recovery database, and the random key protecting that database. These items use the WhenUnlockedThisDeviceOnly accessibility class. Keychain and Data Protection create a meaningful device boundary, especially while the phone is locked, but this architecture is different from a nonexportable Secure Enclave key.

When you draw the pattern, CommonCrypto derives the vault key in the app process. CryptoKit and Vaultaire’s CryptoEngine then use symmetric key bytes in that process to authenticate and decrypt the index, unwrap the master key, and process files. The app clears active state when it locks, but a sufficiently privileged attacker observing an unlocked session has a different opportunity than an examiner holding only locked-device ciphertext.

A jailbroken or otherwise compromised operating system can target pattern input, app memory, decrypted previews, exports, or the screen. Vaultaire recommends a current, non-jailbroken iPhone because the design relies on iOS process isolation, Keychain, and Data Protection. It does not claim that root compromise leaves an open vault’s symmetric keys inaccessible.

Per-File Initialization Vectors

When you encrypt two identical files with the same key, a naive implementation would produce identical ciphertext. This is a problem. An attacker who sees two identical encrypted blobs knows — without decrypting anything — that the two original files are the same. In a vault full of photos, this kind of pattern analysis can reveal information even through encryption.

Vaultaire prevents deterministic ciphertext by generating a fresh cryptographic nonce for each AES-256-GCM sealing operation. File headers and file content are sealed separately, and large files use an authenticated streaming format with a random base nonce and a distinct nonce for each ordered chunk. Two copies of the same photo therefore do not produce the same encrypted representation.

The nonces are stored with the ciphertext and are not secret; their security requirement is uniqueness under a given key. Vaultaire requests 96-bit nonces from Apple’s cryptographic random generator for single-shot encryption and records the base nonce in the streaming header. Collision risk is governed by the number of encryptions under one key, so the implementation generates a fresh value rather than presenting the 96-bit size as a fixed one-in-2⁹⁶ lifetime guarantee.

Memory Management: Clearing Active Key State

A common failure in security software is leaving sensitive data in memory after it is no longer needed. Encryption keys, derived passwords, and decrypted data can persist in RAM long after the app has finished using them. Forensic tools can dump device memory and search for these remnants — a technique known as a cold boot attack or memory dump analysis.

Vaultaire limits how long active key state and decrypted UI data remain available. When the app locks or the session is torn down, its code follows several cleanup paths:

• Active vault state is dropped. The app removes its current vault-key session and requires another unlock before presenting vault content.
• Key wrappers clear owned buffers. Vaultaire’s secure byte containers overwrite the buffers they own when those containers are deallocated.
• Cached master-key state is invalidated. The decrypted master key held for the open index is discarded on the relevant lock and cache-reset paths.
• Decrypted UI caches are cleared where controlled by Vaultaire. Thumbnail and preview cleanup reduces residual application state, without claiming control over every copy made by Swift, iOS, or another process.

The next time Vaultaire opens in a locked state, you draw the pattern and the app derives the vault key again before it can authenticate the index and unwrap the master key. This is session cleanup, not a claim that every transient memory copy received a provable multi-pass wipe or that a Secure Enclave key reference was destroyed. A crash causes iOS to reclaim the process, but cleanup code cannot run after every abrupt termination.