Security Architecture: The Full Technical Stack

The Cryptographic Stack

Most security apps pick one encryption algorithm and call it a day. Vaultaire uses six distinct cryptographic mechanisms working in concert, each chosen for a specific threat model. File contents are encrypted with one cipher. Metadata is encrypted with another. Keys are derived through a computationally expensive function. Hardware security stores the result. And a zero-knowledge architecture ensures that even the people who built Vaultaire cannot access your data.

This is not complexity for its own sake. Each layer addresses a different attack surface. AES-256-GCM handles bulk file encryption because it is fast and hardware-accelerated on Apple silicon. ChaCha20 protects metadata because it is constant-time and resistant to cache-timing attacks. PBKDF2 derives keys through hundreds of thousands of iterations, making brute-force attacks computationally prohibitive. The Secure Enclave stores key material because software-only protection is not enough when someone has physical access to your device.

Together, these layers form a defense-in-depth architecture. An attacker would need to break multiple independent cryptographic primitives simultaneously — a scenario that sits firmly in the realm of the mathematically impossible.

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. This is the same cipher used by the U.S. government for top-secret classified information. It is not a marketing comparison. It is literally the same algorithm, the same key size, and the same mode of operation.

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 2⁸⁰ 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

Your encryption key does not come from nowhere. It is derived from your pattern (or secret phrase) through a key derivation function — an algorithm specifically designed to turn a human-provided input into a cryptographic key. Vaultaire uses PBKDF2 (Password-Based Key Derivation Function 2) with HMAC-SHA512, a NIST-recommended standard used across government and financial systems worldwide.

How PBKDF2 Protects Your Pattern

The core idea behind PBKDF2 is deliberate slowness. It takes your pattern and runs it through hundreds of thousands of rounds of cryptographic hashing. Each round takes a tiny fraction of a second. For you, drawing your pattern and waiting for decryption is nearly instantaneous. For an attacker trying to guess patterns by brute force, that fraction of a second multiplies by every single guess.

Vaultaire configures PBKDF2 with a high iteration count specifically calibrated for modern hardware. At these parameters, each key derivation attempt takes meaningful computational work. An attacker trying a billion pattern guesses would need years of continuous computation — for a single vault. And that assumes they know the salt, which is unique to each vault and stored on your device.

Every vault gets its own cryptographically random salt. This means two users who happen to draw the same pattern will produce completely different encryption keys. Precomputed lookup tables (rainbow tables) are useless because the salt makes each vault’s key derivation unique. The attacker must start from scratch for every vault they target.

ChaCha20: 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 encrypts all metadata with ChaCha20, a stream cipher designed by Daniel J. Bernstein. ChaCha20 is used alongside AES rather than instead of it for a specific reason: cryptographic diversity.

Why a Separate Cipher for Metadata?

Using the same algorithm for both file contents and metadata means that a theoretical breakthrough against that algorithm would expose everything at once. By using AES-256-GCM for file contents and ChaCha20 for metadata, Vaultaire ensures that even in the extraordinarily unlikely event that one cipher is compromised, the other layer remains intact.

ChaCha20 also has practical advantages for metadata. It is a pure software cipher — it does not rely on hardware AES instructions — which makes its performance perfectly constant regardless of the data being encrypted. This eliminates cache-timing side channels, a class of attack where an adversary measures how long encryption takes to infer information about the key or plaintext. For small, structured data like metadata, this constant-time property is especially important.

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 is built on zero-knowledge architecture. This means the company that makes Vaultaire never has access to your encryption keys, your pattern, your secret phrase, or your unencrypted data. Not during sync. Not during backup. Not ever. The cryptographic operations happen entirely on your device. What leaves your device — if anything does — is already encrypted with keys that only you possess.

What Zero-Knowledge Means in Practice

If a law enforcement agency serves Vaultaire with a subpoena demanding your data, the company can comply fully and hand over exactly nothing useful. There are no keys to surrender. There is no master password. There is no backdoor. The encrypted blobs stored in iCloud are mathematically indistinguishable from random noise without your key, and your key exists only in your head (as a pattern) and momentarily in your device’s Secure Enclave (while the app is open).

This is not a policy decision. It is an architectural one. Vaultaire cannot access your data, regardless of intent, incentive, or legal pressure. The system is designed so that the capability does not exist.

Secure Enclave Integration

Software-only security has a ceiling. No matter how carefully an app handles encryption keys in memory, the operating system, other apps, or physical access tools could theoretically read that memory. Apple’s Secure Enclave removes this vulnerability by providing a hardware-isolated environment for key operations.

The Secure Enclave is a dedicated coprocessor built into every modern iPhone. It has its own encrypted memory, its own boot process, and its own security boundary. Keys stored in the Secure Enclave never leave it — not even the main processor can read them. Instead, the app sends data to the Secure Enclave, which performs cryptographic operations internally and returns only the result.

Vaultaire uses the Secure Enclave for key management. When you draw your pattern and the key derivation function produces an encryption key, that key is handed to the Secure Enclave. All subsequent encrypt and decrypt operations are delegated to the hardware. The key never exists in the app’s memory space in a form that could be extracted by a debugger, a jailbreak tool, or a forensic imaging system.

This means that even if an attacker has root access to your iPhone — a scenario that requires a sophisticated jailbreak — the encryption keys remain inaccessible. The Secure Enclave is a separate chip with its own silicon. Compromising iOS does not compromise the Enclave.

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 eliminates this by generating a unique, cryptographically random initialization vector (IV) for every single file. The IV is combined with the encryption key during the AES-256-GCM operation, ensuring that even byte-for-byte identical files produce completely different ciphertext. Two copies of the same photo, encrypted with the same key, will look like entirely unrelated random data.

The IVs are stored alongside the encrypted files but are not secret — their security comes from uniqueness, not confidentiality. Each IV is generated using the device’s cryptographic random number generator, which draws entropy from hardware noise sources. The probability of generating the same IV twice is astronomically small: roughly 1 in 2⁹⁶ for GCM’s 96-bit IVs.

Memory Management: Keys That Self-Destruct

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 takes an aggressive approach to memory hygiene. When you close the app or lock your vault, the following happens in immediate sequence:

• Encryption keys are overwritten. The memory locations holding key material are filled with zeros, then random data, then zeros again. This is not a simple deallocation — the memory is actively wiped to prevent recovery.
• Derived key material is purged. Intermediate values from the PBKDF2 computation, temporary buffers, and any cached decrypted data are zeroed out.
• Secure Enclave keys are invalidated. The key references in the Secure Enclave are marked for destruction, ensuring they cannot be reused without re-deriving from the pattern.
• Decrypted thumbnails and previews are cleared. Any cached image data in memory is overwritten before the app fully closes.

The next time you open Vaultaire, you start from scratch. You draw your pattern, the key is derived fresh, and the Secure Enclave receives a new key reference. There is no session token, no cached credential, and no shortcut. Every app launch is cryptographically independent from the last.