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.
Security Architecture
Trust what you can verify.Not absolute promises.
This is the security architecture of BlindLock’s local password vault. The model assumes the attacker may already have your file. That still is not enough: opening the vault also needs your password and your device.
Local vault unlock: 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 2 · something you know
Your password
Your master password stays with you. BlindLock never transmits it to BlindLock 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 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 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.
Hardware sealing via TPM / Secure Enclave. The vault file alone is not enough. BlindLock seals a non-extractable contribution in your device’s security chip — TPM 2.0 on Windows and Linux, Apple Secure Enclave on macOS, StrongBox/TEE on Android. That contribution feeds key derivation. If the file is copied and opened on another machine, the chip is missing — the vault stays closed. In short: file + password without your device is not enough.
Optional — strongly recommended by BlindLock: a FIDO2 security 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 login: without the physical key — or your recovery phrase as a fallback — the data is mathematically unreadable afterward.
Dual AEAD for the login-stego vault. 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-stego PNG.
Memory-hard password derivation. Before your password becomes cryptographic key material, it runs through Argon2id — deliberately memory-hungry. That makes password guessing hard to parallelize on GPUs or ASICs. Every single guess costs real memory and time. Parameters are attested by the device security chip and range from 512 MiB to 4 GB per derivation depending on hardware. In short: the harder the derivation, the more expensive offline guessing against a stolen vault file becomes.
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. They protect scoped network connections and signatures. They do not wrap that vault file: it uses classical 256-bit dual AEAD. Not a blanket “post-quantum vault” claim — the official specifications are at NIST under FIPS 203 and FIPS 204.
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 physical security key
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 I do not hold cannot leak.
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.
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. 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.
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 I do not possess cannot be stolen from me: this statement applies specifically to vault contents. BlindLock still processes the limited technical and purchase data described in my 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.
Security guides
Go deeper on each layer.
Cloudless storage, privacy boundaries, hardware binding and steganography — same architecture, focused pages.
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.