Pattern-Based Key Derivation: How Vaultaire Turns a Drawn Shape into AES-256 Encryption

Rasty Turek — Sun, 15 Mar 2026 06:16:15 +0000

Most vault apps use a 4-6 digit PIN as an access code. The PIN unlocks the app, and the files behind it may or may not be encrypted. Vaultaire does something different: the pattern you draw IS the encryption key material.

Here's how the pipeline works:

User draws a pattern on a 5x5 grid, connecting at least 4 dots
The dot sequence is serialized into a byte array
The byte array is fed into PBKDF2 with a per-vault random salt and 600,000 iterations
PBKDF2 outputs a 256-bit key
That key is used for AES-256-GCM file encryption with a unique IV per file
When the app closes, the key is wiped from memory

The interesting part is step 3. PBKDF2 (Password-Based Key Derivation Function 2) is deliberately slow. Each guess costs ~1ms of computation. An attacker trying a billion patterns faces a million seconds — about 11.5 days — per vault. And they don't know which pattern is "correct" because there's no verification oracle: every pattern produces a valid-looking key.

Why not Argon2? CryptoKit on iOS doesn't support it natively. Bringing in a third-party implementation means trusting unaudited code for the most security-critical operation in the app. PBKDF2 at 600K iterations with unique salts meets NIST SP 800-132 recommendations. When Apple adds Argon2 to CryptoKit, I'll migrate.

The 5x5 grid gives roughly 53 billion possible patterns (connecting 4+ dots with order mattering). Combined with the slow KDF and per-vault salt, this produces usable security for the consumer threat model: casual snooping, device seizure, and coercion scenarios.

For the full architecture including ChaCha20 metadata encryption and Secure Enclave integration.

DEV Community: Rasty Turek

Pattern-Based Key Derivation: How Vaultaire Turns a Drawn Shape into AES-256 Encryption