Security Architecture

Trust math.
Not promises.

BlindLock's security model assumes the attacker may already have your file. That still is not enough: opening the vault also needs your password and your device.

First the gate, then three keys.

BlindLock opens in two stages. First the gate: your PIN. It is not a security factor — it only protects the entrance to the app. After the gate, three things are needed at the same time to actually open the vault: your file, your password, and your device. If even one is missing, the vault stays closed.

The gate: your PIN

Your PIN runs through Argon2id — a memory-hard key derivation over 256 MiB of memory, with its iterations calibrated per device so that a single check takes around 10 seconds. The PIN is not a vault key and is not the chip’s native auth policy. It gates unlock of BlindLock’s hardware-sealed app anchor on TPM 2.0 / Secure Enclave / StrongBox: a wrong PIN fails the unlock path in the app. This is a deliberately slow entry gate against brute force, not a vault factor. The three factors that actually decrypt the vault come only after the gate.

Factor 1 · something you have

Your file

Your complete password vault is concealed inside an ordinary-looking PNG carrier. Without the correct file, the vault cannot be opened.

Factor 2 · something you know

Your password

Your master password stays with you. BlindLock never transmits it to our servers.

Factor 3 · something you own

Your device

A non-exportable anchor is sealed in the device's security hardware — TPM 2.0, Secure Enclave or StrongBox, depending on the platform. The same carrier and password do not produce a usable vault key on unauthorised hardware.

Optional: a fourth factor you can hold

If you want even more protection, you can also activate a security key — a modern FIDO2 key that supports sealing, for example a YubiKey 5, a current Google Titan key, or a SoloKey. The key cryptographically seals your login: from then on the vault only opens when that small key is plugged in and confirmed during login — or with your recovery phrase as the escape hatch.

Concealed on disk. Absent from our servers.

Cloud managers keep encrypted customer vaults centrally. BlindLock keeps your password vault on your device and hides it inside an ordinary-looking photo.

Your complete password vault hides inside an ordinary file. Passwords, notes and TOTP secrets are encrypted and then embedded steganographically into a PNG of your choice. Steganography means hiding information inside an ordinary-looking carrier; it adds concealment but never replaces encryption.

Large files use separate disguised containers. Documents, media and archives live in their own encrypted file-vault containers. These are designed without an obvious vault signature and can be disguised as unremarkable files such as .zip, .mp4 or .iso.

Your files remain secure inside the file vault. The file vault is a separate encrypted system for documents, images, videos and other files. Unlike VeraCrypt, BlindLock does not mount a virtual drive in the operating system. You can open and edit supported file formats directly in BlindLock. As long as they remain in the vault, BlindLock does not store them as unencrypted files on your device. You can export other file formats when needed. You choose the destination, and only then does BlindLock create an unencrypted copy of the file there.

Long-term ciphertext risk.

Encrypted data stolen today can be stored and attacked later. BlindLock’s answer starts with architecture: there is no central vault database to harvest, and your resting vault file uses 256-bit authenticated encryption. Under known quantum attacks on symmetric crypto, that remains in a work-factor class generally treated as impractical — not a claim that quantum computers cannot affect cryptography at all.

NIST post-quantum components in the stack. BlindLock includes ML-KEM-1024 (FIPS 203) and ML-DSA-87 (FIPS 204) for scoped uses documented on this page. They do not wrap the resting password vault; that ciphertext uses classical 256-bit dual AEAD. Deployment scope is listed on this page — not as a blanket “post-quantum vault” claim.

Dual AEAD for the login-stego vault. Login-stego vault payloads use AES-256-GCM under XChaCha20-Poly1305 (192-bit nonce), each with independent keys. Larger file-vault containers use authenticated encryption as documented on this page.

Memory-hard password derivation. Your password is stretched with Argon2id — memory-hard, with parameters hardware-attested and scaled to the device, between 512 MiB and 4 GB. Every single password guess costs a full memory-hard pass, which is what makes offline brute force impractical. The roughly 10 seconds you may notice is in part UX pacing; the security is the memory-hard work per guess, not the stopwatch.

Factor 3 in detail — the authorised device is required.

The third factor is your device. A non-exportable hardware anchor participates in key derivation through TPM 2.0, Secure Enclave or StrongBox, depending on the platform. Copying the carrier to unauthorised hardware does not reproduce that factor, so the vault stays closed.

Windows & Linux

The link to your device is anchored in the TPM 2.0 security chip, whose sealed key salts the derivation. A copied file plus the correct password is not enough on another computer, because that salt cannot be reproduced there.

macOS

Apple Secure Enclave (Apple Silicon) or T2 holds hardware-bound credentials. The enclave enforces per-operation rate limits that an attacker cannot bypass in software.

iOS, iPadOS & Android

Secure Enclave anchors the device factor on iPhone and iPad; supported Android devices use StrongBox-backed hardware protection.

Slow unlock, progressive lockout

Failed unlocks are slowed by memory-hard Argon2id work and progressive lockout in the app. A hardware monotonic counter helps detect rollback of lockout state — that is not the same as the chip enforcing a native PIN auth policy.

Optional: a security key you plug in

If you want, you can additionally seal your login to a physical security key — a modern FIDO2 key with sealing capability (hmac-secret), for example a YubiKey 5, a current Google Titan key, or a SoloKey. Then the vault only opens when, on top of your file, password, and device, that key is plugged in and confirmed; without it, only your recovery phrase remains as the escape hatch. Keys without sealing capability are rejected during activation.

The key's PIN stays with the OS. If your key has its own PIN, Windows or macOS asks for it in its own window — straight between keyboard and key. BlindLock never sees, stores, or logs that PIN. What we do not hold cannot leak.

We cannot see your vault — because it never reaches us.

BlindLock never transmits vault contents to our servers. They leave your device only through an action you choose, such as an export or placing a backup file in a folder you sync yourself.

No central customer-vault database. No BlindLock cloud account is required to store your vault, and we operate no central vault-sync or vault-backup service. A breach of our infrastructure therefore cannot expose a collection of customer vaults that we do not possess.

Clear network boundaries. Activation and each new unlock use a brief encrypted connection for licence entitlement and version checks. Technical licence, device, platform and version information is exchanged — never passwords, notes, 2FA secrets or files.

Auditable OSS boundary. The cryptographic and steganographic primitives are built on open, publicly verifiable libraries (libcrux / HACL*). The vault UI, licence handling and the vault/steganography code built on top are proprietary; the cryptographic primitives protecting your ciphertext are open and publicly verifiable.

What we do not possess cannot be stolen from us: this statement applies specifically to vault contents. BlindLock still processes the limited technical and purchase data described in our privacy policy →

What BlindLock defends against — and what it doesn't.

No software protects you from a keylogger running on your own machine while you type your PIN. Honest threat modelling is part of the product.

Defended

Lost or stolen devices, copied carrier and file-vault files, provider-side mass theft of customer vaults, harvest-now-decrypt-later risks, offline password guessing and physical access attempts against encrypted data at rest.

Not defended

A compromised operating system running with your active user session (keyloggers, screen capture, memory scraping). BlindLock implements runtime hardening to raise the cost, but a fully compromised host is out of scope — that's where security keys and OS hygiene matter.

Trust the math — and secure Lifetime.

Concealment, authenticated encryption and hardware-bound keys in one local vault. Lifetime pricing opens soon — phases from €59.