1 · where your vault lives
Your login image
Your entries are encrypted and concealed inside an ordinary-looking photo. Without exactly this file there is nothing to open. The file alone, however, does not yield a usable key.
Security Architecture
Trust what you can verify.Not absolute promises.
This is the security architecture of BlindLock’s local password vault. It has three independent layers: concealment, encryption and hardware binding. The threat model assumes an attacker has already copied your carrier file and explains openly which hurdles remain.
Local vault unlock: first the gate, then key and password.
BlindLock opens in two stages. First the gate: your PIN. It does not decrypt the vault — it gates the release of the hardware-bound app anchor and is deliberately compute-heavy. Only then does the login image open. The key to your login image depends on your device's security chip and a release from the BlindLock licence server. To sign you in, BlindLock also asks for your master password.
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: a wrong PIN fails the unlock path in the app. This is a deliberately slow entry gate against brute force, not a vault factor. Only after the gate does the key to your login image come about, and BlindLock checks your master password.
2 · what the key is made of
Chip and server release
The key to your login image depends on your device's security chip and a release from the BlindLock licence server. One part of the key, kept sealed by the security chip, only opens on this device, in the Apple Secure Enclave or the TPM 2.0. On another computer no usable key comes about. The vault stays closed.
3 · something you know
Your master password
To sign you in, BlindLock also asks for your master password. Only you know it, and it never leaves your device. BlindLock checks it with Argon2id, using 1 to 4 GB of memory per try depending on the device.
Optional: a hardware key you can hold
If you want even more protection, you can also activate a hardware 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 access: from then on the vault only unlocks when that small key is plugged in and confirmed during login — or with your twelve words as the escape hatch.
Concealed on disk. Absent from BlindLock 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 encrypted containers. Documents, media and archives live in their own encrypted file-vault containers. These are designed without an obvious vault signature. On request you can create them with an unremarkable extension such as .zip, .iso or .dmg.
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.
Hardware sealing via TPM / Secure Enclave. The vault file alone is not enough. One part of the key, kept sealed by your device’s security chip, only opens on this device — TPM 2.0 on Windows and Linux, Apple Secure Enclave on macOS. Together with a release from the BlindLock licence server it forms the key to your login image. If the file is copied and opened on another machine, the chip is missing and no usable key comes about. The vault stays closed, even for someone who knows your password.
Optional — strongly recommended by BlindLock: a FIDO2 hardware key. On top of the device chip, you can activate a physical key. BlindLock accepts only modern FIDO2 keys that support sealing (the FIDO2 “hmac-secret” extension). Examples: YubiKey 5-series, current Google Titan keys, SoloKeys. The list is open: any key with that capability works, regardless of vendor. Older or 2FA-only keys without sealing are rejected at activation with a clear message. Once activated, the key cryptographically seals your access. Without it the vault can no longer be unlocked. Your twelve words remain as the fallback.
Dual AEAD for your login image. The vault hidden in your PNG is encrypted twice with authenticated encryption: AES-256-GCM, then XChaCha20-Poly1305 (192-bit nonce), each with an independent key. “Authenticated” means tampering with the encrypted contents is detected, not only confidentiality. Larger file-vault containers also use authenticated encryption — not the same dual stack as the login image.
Memory-hard password hardening. BlindLock checks your master password with Argon2id, using 1 to 4 GB of memory per try depending on the device. For file vaults, Argon2id derives the key itself from the vault password, with at least 512 MiB. That makes guessing against a copied file vault hard to parallelize on GPUs or ASICs.
NIST post-quantum components in the stack. Quantum computers mainly threaten classical public-key cryptography (key exchange and signatures) — not the same attack path as against the vault file on your device. BlindLock therefore includes the NIST standards ML-KEM-1024 (FIPS 203, key encapsulation) and ML-DSA-87 (FIPS 204, signatures), security level 5, via libcrux. ML-KEM-1024 and ML-DSA-87 are reserved for pairing with the upcoming mobile apps. Where the BlindLock servers support it, licence and update connections use a hybrid key exchange (X25519 + ML-KEM-768). None of these building blocks wraps your vault files: your login image uses classical 256-bit dual AEAD, file vaults use classical authenticated encryption. Not a blanket “post-quantum vault” claim — the official specifications are at NIST under FIPS 203 and FIPS 204.
Hardware binding in detail — the vault is useless without your device.
BlindLock binds your login image to this one computer — through its built-in security chip (TPM 2.0 on Windows/Linux, Apple Secure Enclave on macOS). If your file is copied and opened on another computer, no usable key comes about there and the vault stays closed.
Windows & Linux
The link to your device is anchored in the TPM 2.0 security chip, which seals one part of the key. A copied file plus the correct password is not enough on another computer, because that part cannot be opened there.
macOS
The Secure Enclave on Apple Silicon holds hardware-bound credentials.
Slow unlock, progressive lockout
Failed unlocks are slowed by memory-hard Argon2id work and progressive lockout in the app. A counter helps detect rollback of lockout state: a hardware counter in the TPM on Windows and Linux, a Secure-Enclave-sealed counter on macOS. That is not the same as the chip enforcing a native PIN auth policy.
Optional: a physical hardware key
If you want, you can additionally seal your login to a physical hardware key — a modern FIDO2 key with sealing capability (hmac-secret), for example a YubiKey 5, a current Google Titan key, or a SoloKey. Then BlindLock only unlocks on this device when, on top of your PIN and master password, that key is plugged in and confirmed. Without it, only your twelve words remain as the escape hatch. Keys without sealing capability are rejected during activation.
The key's PIN goes straight to the key. If your key has its own PIN, Windows asks for it in its own operating-system window. On macOS and Linux you type it into BlindLock, which passes it straight to the key and does not store it.
I cannot see your vault — because it never reaches me.
BlindLock never transmits vault contents to BlindLock 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 I operate no central vault-sync or vault-backup service. A breach of BlindLock infrastructure therefore cannot expose a collection of customer vaults that I do not possess.
Only one part may reach the network. BlindLock itself never talks to the internet. Everything that has to go out runs through a separated part that cannot see your vault and receives nothing from it.
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. The server returns a 32-byte value that goes into your vault key. If the server is unreachable, BlindLock opens for up to seven days after the last contact with a permit issued by the server, bound to the device and sealed by the security chip.
Open building blocks, proprietary code. The encryption building blocks come from open, publicly available libraries (libcrux by Cryspen, plus Argon2id and BLAKE3). Steganography, vault UI, licence handling and the vault code built on top are proprietary.
Licence and support systems still need protecting. Even an incident in those systems exposes no store of BlindLock customer vaults, because BlindLock does not keep such vaults. BlindLock processes only the limited technical and purchase data described in my privacy policy →
What BlindLock defends against — and what it doesn't.
BlindLock reduces central and file-based attack surfaces. It does not replace a trustworthy operating system and does not protect against malware that controls an already unlocked device, such as a keylogger reading your PIN.
Defended
BlindLock makes access harder after a locked device is lost or stolen, after a carrier file is copied, and against offline guessing on file vaults. With no central vault database, there is also no mass theft of customer vaults through a single provider breach. That reduces exposure to harvest-now-decrypt-later risks.
Not defended
A compromised operating system running with your active user session (keyloggers, screen capture, memory scraping). BlindLock hardens its runtime, but a fully compromised device is out of scope. That calls for a trustworthy, maintained operating system and good endpoint security.
Security guides
Go deeper on each layer.
Cloudless storage, privacy boundaries, hardware binding and steganography — same architecture, focused pages.
Cloudless vault Why your vault lives only on your computer.
Privacy Why BlindLock learns nothing about your vault.
Hardware binding How the security chip binds your vault to your device.
Steganography How your vault hides inside an ordinary image.
Compare How BlindLock differs from LastPass, 1Password and Bitwarden.
Trust what you can verify — and secure Lifetime.
Concealment, authenticated encryption and hardware-bound keys in one local vault. Lifetime licences from $49, available now.