Frequently asked questions.

BlindLock keeps passwords, notes and 2FA secrets fully encrypted and steganographically concealed inside an ordinary-looking PNG file on your device. Opening it takes three things at once: the carrier file, your master password and the authorised device — the vault key is sealed to that device's security chip, which is TPM 2.0, Secure Enclave or StrongBox depending on the platform. 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.

Cloud managers store encrypted customer vaults centrally. BlindLock stores your password vault inside a PNG carrier on your device using steganography and operates no central customer-vault database. Concealment, encryption and hardware binding remove a major central attack surface.

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.

None of that would be worth much if I were dishonest here. 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. I say so plainly.

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 three hurdles between him and your data: his knowledge that this one image holds anything at all, your password, and your hardware. Add a security key and it is four. At three, success is already very unlikely. At four it is practically hopeless.

I still do not promise an absolute guarantee. Nobody who stays honest can give one.

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.

Wallet network features do not talk to me at all. They talk directly to vetted blockchain nodes, and only if you switch them on. What travels there is public addresses and balance queries. Private keys, seed phrases, passwords and notes are excluded.

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

Two technical facts are exchanged and nothing else: whether your licence is valid and which version of the program you have installed. 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. 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. Wallet network features only reach out if you switch them on yourself, and then exchange public addresses and transaction data with vetted blockchain nodes.

The cryptographic layer uses standard, peer-reviewed building blocks. Login-stego vault payloads 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. Key derivation runs through Argon2id, 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. The vault key itself is derived over 512 MiB to 4 GB depending on the device — every single password guess forces a full memory-hard pass. The ~10 seconds a 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. Where each component is deployed is documented on the Security page. 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, Secure Enclave or StrongBox, 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.

Opening needs three things at once: the image file, your password, and a key that was generated inside this one machine's security chip and cannot leave it. That hardware key goes into the key derivation, so on any other machine the derived key is simply wrong. 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 — a construction that remains in a work-factor class generally treated as impractical under known quantum attacks on symmetric crypto. The stack also includes the NIST post-quantum components ML-KEM-1024 (FIPS 203) and ML-DSA-87 (FIPS 204), security level 5. Where each component is deployed is documented on the Security page.

A copied carrier alone is not enough on a new device. Before an emergency, create an encrypted BlindLock backup and keep its recovery phrase separately — both are required to restore on authorised replacement hardware. Without the required recovery material, BlindLock cannot recover the vault for you.

The same holds if the security chip dies or the machine is gone altogether. At setup you write down twelve words and you are asked to confirm them, so a wrong copy is caught while it still costs nothing. Your image, your backup file and those twelve words rebuild your login on a new machine and bind it to the new 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. The login needs the image, the backup file and the twelve words together. On another device a vault needs its vault file, its password, the same backup file and the same twelve words. Each of them runs through a memory-hard derivation sized to the machine, 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. If you still have a valid encrypted BlindLock backup and its separately stored recovery phrase, restore on authorised hardware. Without that backup material, the vault cannot be recovered for you.

BlindLock accepts modern FIDO2 security 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 you activate it, it cryptographically seals your unlock. Without the physical key — or your recovery phrase as a fallback — your data is mathematically unreadable afterward. Older keys without the required capability are rejected during activation with a clear message, instead of a half-promise.

No. When your FIDO2 security key has a master PIN set on it, the prompt you see comes from the operating system's native security-key dialog — not from BlindLock. Your PIN goes straight from the keyboard into the key's chip. BlindLock never reads it, never stores it, never caches it, never logs it. It is structurally impossible for me to leak a PIN I do not hold.

This is also why there is no "BlindLock PIN" for the security 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, and it never leaves the silicon.

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 security 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 or T2) and Ubuntu 22.04 or newer, 64-bit (TPM 2.0). iOS and iPadOS 17+ (Secure Enclave) and Android 12+ (StrongBox) follow as free apps. Full requirements are on the platforms page.

Yes. iOS, iPadOS and Android are always free, for everyone. The same local-first security model applies on mobile: Secure Enclave for iPhone and iPad, and StrongBox on supported Android devices. 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 recovery phrase. 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 phases: 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. Security-critical releases may require a minimum version, while routine updates remain optional.

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.

At checkout you must confirm immediate digital delivery and waive the right of withdrawal. After that confirmation there is no withdrawal. Full details on the Refunds page.

Login-stego vault payloads 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 for memory-hard key derivation (256 MiB for the PIN that gates BlindLock's hardware-sealed app anchor, 512 MiB to 4 GB depending on the device for the vault key — a check takes around 10 seconds, but the protection is the memory-hard work per guess). 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. 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.

Selected cryptographic building blocks come from open, publicly verifiable libraries (libcrux / HACL* lineage). The steganography engine, vault UI, licence layer and platform integrations built on top are proprietary.

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 recovery phrase 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. Team capabilities may come later as a separate product, if I can ship them without weakening the security model.

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