Only you can read your page. Here's the proof.

1What's encrypted - and what isn't

Every section of your page - who to call, cards and accounts, insurance, hotel, documents, your checklist - is encrypted as one sealed block. Two things stay readable on purpose:

• Your page name - it's the URL. That's what makes the page reachable from any borrowed device, which is the whole point.
• Your headline - the one public line shown on the locked page, so you can confirm you've found the right page before unlocking. Don't put secrets in it; everything else goes inside the sealed block.

2How the key is made

Unlocking takes two ingredients you carry in your head - your name and your PIN or passcode - plus one ingredient our server holds. The clever part is how the server contributes its ingredient: it mixes a secret of its own into your key blindly, through a cryptographic exchange in which it never sees your name, your PIN, or the finished key. The mixing happens on your device; the server just stirs, with its eyes closed.

The result: the finished key exists only in your browser, only for the moment it's needed. It is never sent anywhere and never stored on our side - so there is nothing on our servers that could decrypt your page.

3Why a 6-digit PIN can't be brute-forced

A fair question - a million combinations is nothing for a computer. It's nothing, that is, when the computer can test guesses offline, against a file it already has, billions of times per second. Our design takes that option away: because the server's blind ingredient is part of every key, each guess requires a live round-trip to our server. The server throttles repeated attempts with escalating delays and a human check - each guess costs a slow, monitored request instead of a nanosecond.

And because this is a recovery product, there is deliberately no hard lockout - a stranger hammering your page can never lock you out of it. Attempts get slower and more annoying for the attacker; your one correct entry still works. If you want more margin than a PIN, choose a longer passcode - the scheme is the same, the guessing space just gets astronomically bigger.

4What a breach of our servers would reveal

Suppose someone stole a complete copy of our database tomorrow. They would have: encrypted blobs they cannot read, page names, headlines, account emails, and billing references. No page content, no names (as used for keys), no PINs, no keys - none of that ever reaches us. Even the blind-mixing secret is kept in a separate trust domain from the data, so a database breach alone doesn't even enable an offline guessing attack. The same logic applies to legal demands: we cannot hand over what we cannot read.

5What we can't protect you from

Anyone who claims their security has no limits is selling something. Ours, honestly:

• Forgetting both your name-as-set and your PIN. There is no reset, no backdoor, no support ticket that fixes this. You'd set the page up again.
• Someone who knows both your name and your PIN. The crypto can't tell your partner from a thief who read your PIN over your shoulder. Pick a PIN that isn't your birthday; or a longer passcode (recommended).
• A compromised device. If the computer you type your PIN into is running a keylogger, no encryption scheme on Earth helps. On a device you don't trust, decline the "remember on this device" option - your key then lives only for that tab.
• Us turning malicious. Like every product that encrypts in the browser, you trust the code we serve you. We keep that honest by keeping third-party scripts off the pages that handle your key and by keeping the decrypt path small and auditable - but it's right that you know the trust boundary exists.

6The exact scheme, for security reviewers

Content is sealed client-side with Web Crypto. The key derivation:

input      = domain-tag ‖ len(name) ‖ name ‖ len(secret) ‖ secret
oprfOut    = VOPRF(server, input)          // RFC 9497, P-256/SHA-256, DLEQ-verified
localIkm   = PBKDF2-SHA-256(input, salt, 600,000)
key        = HKDF-SHA-256(localIkm ‖ oprfOut, salt, context)
ciphertext = AES-256-GCM(iv, key, content, AAD = envelope header)

• Layered key, two independent defenses. With only the public ciphertext, an attacker must query the rate-limited OPRF per guess - online only. If the server-side OPRF key were also compromised, the scheme degrades to offline PBKDF2 at 600,000 rounds - no worse than a conventional password-based design.
• The OPRF is oblivious and verifiable. The server evaluates a blinded input - it learns nothing about name, secret, or key - and returns a DLEQ proof the client verifies against the page's published public key, so a malicious server can't substitute results. Server-side, each page gets its own evaluation key derived from an epoch-versioned master key, which binds every blob to its page and keeps key rotation backward-compatible.
• Downgrade-resistant envelope. The stored blob is a self-describing envelope (version, KDF parameters, salt, IV, suite, key epoch). The header is bound into the AES-GCM additional data, and decryption rejects iteration counts below 600,000, unknown KDFs, and non-allowlisted OPRF suites - a tampering server can't weaken old blobs.
• Inputs are canonicalized and unambiguous. NFKC normalization (name additionally case- and whitespace-folded; the secret case-preserved), then a length-prefixed, domain-tagged encoding - no separator collisions, no cross-protocol confusion.
• Keys are non-extractable. Derived keys live as non-extractable CryptoKeyobjects. On a borrowed device, unlock details last only for the tab session. On your own device, opting into "remember" stores the non-extractable key - never your name or PIN - with a 30-day expiry.

7Found something? Tell us.

If you're a security researcher and you think we've gotten something wrong - in the design above or in the code that implements it - we genuinely want to hear it: hello@nowwhat.page.