Frequently asked questions.

BlindLock keeps passwords, notes and 2FA secrets fully encrypted and steganographically concealed inside an ordinary-looking PNG file on your device. The key to your login image depends on your device's security chip (TPM 2.0 or Secure Enclave) and on a release from the BlindLock licence server. To sign you in, BlindLock also asks for your master password. A copied file on its own is therefore not enough to gain access. Larger files live separately in their own encrypted containers, and there is no central vault database for a breach at the provider to harvest.

BlindLock operates no central vault database. Your entire password vault lives encrypted inside the PNG and opens only with your device's security chip and a release from the BlindLock licence server. That removes a central attack surface of classic cloud password managers.

See the full side-by-side comparison.

Encryption answers whether an attacker can read the contents. Concealment answers the question that comes before it: does he even realise there is something to take. A visibly encrypted vault is a target. An ordinary image on your machine is not.

Even so: an image can be stolen, and so can a password. If your operating system is infected with malware that reads keystrokes or siphons off files, BlindLock does not protect you against that.

The decisive difference comes afterwards. Even with the image and the password, the haul is rubbish on the attacker's machine. It only opens on your device, because the vault key is sealed to that device's security chip. He would also need physical access to your computer.

That leaves several hurdles between him and your data. First he has to know that this one image holds anything at all. 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 PIN and your master password. Optionally, BlindLock also asks for a hardware key when you unlock.

Passwords, notes and TOTP secrets live fully encrypted inside the PNG carrier. Larger documents and media use separate encrypted file-vault containers.

Nothing from your vault, ever. BlindLock transmits no vault contents to BlindLock servers and operates no central customer-vault database.

What does reach BlindLock servers is purely technical information from the licence check: licence, device, platform and version details. No entry, no file name, no count.

Vault contents leave your device only when you set that in motion yourself — on export, or when you place an encrypted backup in a cloud folder. They stay encrypted even then, and I never get to see them.

BlindLock has no wallet network features at the moment. WalletLink is announced as Coming Soon. The wallet address book works entirely locally and opens no connection. It has no field for private keys or seed phrases.

Nothing of your content leaves your device. No passwords, no notes, no 2FA secrets, no files and no information about what your vault holds.

Only technical data is exchanged: licence, device, platform and version details, and the server returns a 32-byte value that goes into your vault key. BlindLock fetches that value fresh from the server at every unlock and never keeps it in plain text on your machine. Without it your vault does not open at all. It takes a moment and happens at activation and at every new unlock.

The version part is the real reason for that connection. If a weakness turns up in an older build, I can stop your vault being opened with it and hand you the corrected build instead. BlindLock downloads updates from dl.blindlock.app. Without that brief check you would have to learn about the weakness yourself and act on it yourself.

So that this brief check never becomes a bottleneck, the server issues a seven-day permit at every successful unlock. It is signed by the server, bound to your device and stored sealed by the security chip next to your licence. If the server is ever unreachable, BlindLock opens with that permit until it expires and shows you how long it still runs. As soon as the server answers again, it is renewed on your next unlock. A licence block therefore takes effect without server contact only once the last permit has expired.

After unlocking, the vault carries on locally with no further connection. This includes the wallet address book.

The cryptographic layer uses standard, peer-reviewed building blocks. Entries in the login image use dual AEAD: AES-256-GCM under XChaCha20-Poly1305 (192-bit nonce), each with an independent key. Larger file-vault containers use authenticated encryption as documented on the Security page. Argon2id is a memory-hard function: the PIN passes through 256 MiB of memory and acts as an app entry gate for BlindLock's hardware-sealed app anchor — not the chip's native auth policy and not the vault key. 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. The roughly 10 seconds a PIN check takes is not the protection. The protection is the memory-hard work per guess.

The stack includes the post-quantum components ML-KEM-1024 (FIPS 203) for key encapsulation and ML-DSA-87 (FIPS 204) for signatures, both at NIST security level 5. They are reserved for pairing with the upcoming mobile apps. Where the server supports it, licence and update connections use a hybrid key exchange (X25519 + ML-KEM-768). Resting vault data is protected by classical authenticated encryption. The encryption and post-quantum building blocks (AES-256-GCM, XChaCha20-Poly1305, ML-KEM-1024, ML-DSA-87) come from libcrux, whose core algorithms are checked with formal methods (hax/F*). BlindLock's own vault, steganography and licence code builds on top of them but is not itself part of that formal verification. Hardware binding uses TPM 2.0 or Apple Secure Enclave, depending on the platform.

The steganographic layer is added on top — it does not replace any of that. Even if an attacker detected and extracted the payload, they would face a fully encrypted, hardware-bound ciphertext.

I do not claim the image is undetectable, and nothing in BlindLock rests on that. Someone who suspects a file and runs statistical analysis on it may well flag it. That is exactly why the hiding is a layer, not the lock.

The key to the image depends on a part that the security chip of this one machine keeps sealed, and on a release from the BlindLock licence server. To sign you in, BlindLock also asks for your PIN and your master password. On any other machine the image alone gives no usable key. Copy the image to another PC and it stays shut.

What the hiding buys you is something else: nobody knows there is anything to ask you about.

Standard public-key cryptography will eventually be breakable by a sufficiently large quantum computer, and attackers are already harvesting encrypted data today to decrypt it later. BlindLock's answer is architectural: there is no central vault database to harvest, and your resting vault file is protected by 256-bit symmetric authenticated encryption. By current knowledge this key length is considered sufficient against known quantum attacks as well. The stack also includes the NIST post-quantum components ML-KEM-1024 (FIPS 203) and ML-DSA-87 (FIPS 204), security level 5. They are reserved for pairing with the upcoming mobile apps. Where the server supports it, licence and update connections use a hybrid key exchange (X25519 + ML-KEM-768). The resting vault file stays on classical authenticated encryption. Details are on the Security page.

A copied login image alone is not enough on a new device. To restore on a new machine your backup file and your twelve words are enough. If one of them is missing and you can no longer sign in on any device, there is deliberately no back door.

The same holds if the security chip dies or the machine is gone altogether. At setup BlindLock shows you twelve words. You write them down and BlindLock asks four of them back, so a slip of the pen shows up right away instead of in an emergency. Moving to a new machine then works in two ways. If you still have your login image, take the image, the backup file and the twelve words. If the image is gone, the backup file and the twelve words are enough: BlindLock creates a new login image on the new machine and seals it to that computer's security chip. Your vaults come across the same way: the backup file carries the rescue for every vault you have opened once since setup. On the new machine you then need the vault file, your vault password, the backup file and the twelve words. None of it lives on a server, so I cannot recover anything for you.

It never rests on one secret. You only get your login image back on a new machine with the backup file and the twelve words together. A file vault is independent of that: on another device it needs its own vault file, its own password, the same backup file and the same twelve words. Each of them is protected by a memory-hard derivation, so every guess costs real memory and real time, and no single piece on its own gets an attacker anywhere.

BlindLock cannot reset a forgotten PIN. That is deliberate: a resettable PIN would also be a central back door. If you still have a valid encrypted BlindLock backup and its separately stored twelve words, restore your vault on a new device. Without that backup material, the vault cannot be recovered for you.

BlindLock cannot reset it, and nobody else can either. That is exactly what protects your vault. You still get your entries back: create a new login image with a new master password, then restore your entries into it from your backup file with your twelve words. You need your PIN and an active licence for this. Changes made after your last backup are not included. A file vault opens only with its own vault password.

BlindLock accepts modern FIDO2 hardware keys that support sealing (the FIDO2 "hmac-secret" extension) — for example YubiKey 5-series keys, current Google Titan keys, or SoloKeys.

The list is open: any key that ships this capability works, regardless of vendor.

With BlindLock the key is more than a login prompt. Once activated, the key cryptographically seals your access. Without it the vault can no longer be unlocked. Your twelve words remain as the fallback. Older keys without the required capability are rejected during activation with a clear message, instead of a half-promise.

Store it: no. On Windows the operating system asks for your FIDO2 hardware key's PIN in its own window. On macOS and Linux you type it into BlindLock, which passes it straight to the key and does not store it.

There is no "BlindLock PIN" for the hardware key: FIDO2 authenticators support exactly one master PIN that you configure on the device itself (typically via the vendor's own tool). That same PIN secures every service that uses the key.

BlindLock defends the vault at rest. It cannot defend a fully compromised operating system running under your active user session — keyloggers, screen capture, memory scraping. I implement hardening to raise that cost (anti-debug, screen-protection, clipboard scrubbing).

If your operating system is compromised — for example through remote access by an attacker or direct access to your hardware — that is outside what BlindLock can protect against. In those cases, BlindLock cannot protect against theft or abuse.

For everyday use, what matters most is a maintained, up-to-date operating system, a watchful eye, and ideally a hardware key. BlindLock is built for that — including on the device you use every day. Only if you manage especially critical access can a separate machine be an extra safeguard.

Remember: your entire digital life can be one password away. Lock it down!

Supported today: Windows 10+ (TPM 2.0), macOS 13.3+ (Apple Silicon M1 or newer) and Linux with TPM 2.0: Debian and Ubuntu 22.04 or newer, plus RPM (Fedora, openSUSE) and AppImage. iOS and iPadOS 17+ (Secure Enclave) and Android 12+ (StrongBox) follow as free apps. Full requirements are on the platforms page.

Yes. The iOS, iPadOS and Android apps are coming soon and will always be free, for everyone. Paid Lifetime and later subscription pricing apply to desktop only — one active Windows, macOS or Linux device at a time per paid licence, and that licence moves with you to a new PC.

BlindLock does not operate automatic vault sync. You choose where to keep encrypted backups, including local media, external storage or a cloud-synchronised folder. Migration to a new authorised device uses an encrypted BlindLock backup and the separately stored twelve words. One paid licence covers one active desktop device. iOS and Android remain free.

One paid licence = one active desktop at a time (Windows, macOS or Linux). Replace your PC whenever you like — the licence moves with you through the built-in migration flow. It does not die with the old machine. iOS, iPadOS and Android are always free, for everyone, and do not consume that desktop seat.

BlindLock sells exactly 1,000 Lifetime licences in three waves: 100 at $49, 350 at $89 and 550 at $109. Each is a one-time licence with no expiry date or recurring subscription. Entitlement is verified online at unlock. Every update is required. Once a new version is released, BlindLock opens your vault only after you install it.

After the 1,000 Lifetime licences, BlindLock is subscription-only: $4.99 per month or $39.99 per year — always the latest version including major versions, for as long as the subscription is active. Lifetime will not return. See the pricing page.

During the Lifetime offer, only Lifetime licences are sold. Afterwards, BlindLock becomes subscription-only, with monthly or annual billing and the latest version while the subscription remains active. A Lifetime licence never creates a recurring invoice.

Yes. Every update is required. Once a new version is released, BlindLock opens your vault only after you install it. Your data stays unchanged on your device. BlindLock downloads updates from dl.blindlock.app and checks their signature before installing.

EU consumers have a 14-day right of withdrawal. Before payment, Polar’s checkout shows a required checkbox: you request immediate delivery and confirm that you lose your right of withdrawal once delivery starts. Once the payment succeeds and delivery starts, there is no right of withdrawal for the licence. Full details on the right of withdrawal page.

Entries in the login image use AES-256-GCM under XChaCha20-Poly1305 (192-bit nonce) for dual AEAD with independent keys. File-vault containers use authenticated encryption as documented on the Security page. Argon2id as a memory-hard function: 256 MiB for the PIN that gates BlindLock's hardware-sealed app anchor. A PIN check deliberately takes around 10 seconds, but the protection is the memory-hard work per guess. 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. ML-KEM-1024 (FIPS 203, formerly CRYSTALS-Kyber) for post-quantum key encapsulation. ML-DSA-87 (FIPS 204, formerly CRYSTALS-Dilithium) for post-quantum signatures, both at NIST security level 5. They are reserved for pairing with the upcoming mobile apps. Where the server supports it, licence and update connections use a hybrid key exchange (X25519 + ML-KEM-768). Licence, update and unlock signatures use Ed25519. The encryption and post-quantum building blocks come from libcrux, whose core algorithms are checked with formal methods (hax/F*). The vault, steganography and licence code built on top of them is not part of that verification.

No. BlindLock is proprietary. For encryption it uses established open libraries: libcrux by Cryspen (AES-256-GCM, XChaCha20-Poly1305, ML-KEM, ML-DSA), plus Argon2id and BLAKE3. Steganography, vault, licence layer and platform integrations are BlindLock's own unpublished code.

Back up the active PNG carrier. The original, unmodified source image is not needed after the carrier has been created. For migration and emergencies, also create an encrypted BlindLock backup and keep its twelve words separately. For vaults, also back up the vault file. Their rescue lives in the same backup file. BlindLock writes the backup file to up to four folders you choose, local, external or cloud-synchronised, and checks at every destination that it opens with your twelve words.

BlindLock is built for individual use — one person, one active device, and no central vault sync. Features for teams are being considered for a future release.

Responsible disclosure: email security@blindlock.app. I respond within 72 hours. Please do not open public issues on anything that looks like a vulnerability.