Log In Get Started
Free tool

Encrypt for a recipient

Password encryption runs into the problem that the password has to be passed along somehow — and passed more safely than the message itself. Here that is not needed: the recipient publishes their public key once, you encrypt with it, and only they can read it with their secret key. There is nothing to arrange in advance.

Keys and encryption are computed in your browser. We see neither the keys nor the text.

Leave it empty and the recipient reads the message without learning who sent it. With a key they see whose key encrypted it, and that cannot be forged.

Neither keys nor messages go anywhere: everything is computed in this tab.

How it works between two people

The recipient comes here, creates a key pair and publishes the public one — on a site, in a profile, in a pinned message. The secret one they keep. Anyone who wants to write to them takes that public key, encrypts a message with it and sends the resulting line, even in an open chat. Only the owner of the secret key can read it.

A public key can only encrypt — it cannot decrypt, which is why handing it out is safe. That is the main difference from a password: with a password the same secret both locks and unlocks, and so it has to be transmitted.

The one weak spot

It is not in the cipher but in where you got the public key. Whoever can substitute a message on the way can substitute the key too — and then you encrypt for them, and having read it they forward it on to the real recipient, and nobody notices anything. So the key must come from a different channel than the conversation: the recipient’s website, a pinned message, a business card, from them in person.

Nearby: sign a message, if you need to prove authorship of an open text, encrypt text with a password, when a shared password does exist, and encrypt a file.

We store neither keys nor messages

Just as there are no visit logs in the VPN itself: there is nothing to hand over on request.

How it works →

FAQ

guest@404vpn:~$ cat box-faq.md
[01] $ Why is this better than encrypting with a password? ▸
> Because no shared secret is needed. A password has to be passed through a separate channel, and with a stranger that is a nearly unsolvable task. Here the recipient publishes a public key once — on a site, in a profile — and anyone can write to them. A public key is not a secret: it can only encrypt, never decrypt.
[02] $ What are the two modes — anonymous and signed? ▸
> Anonymous: a one-off key pair is created for each message, and the sender needs no key at all. The recipient reads the message but does not learn who it came from. Signed: you use your own secret key, and the recipient sees whose key it was encrypted with — which cannot be forged. The first mode is for approaching a stranger, the second for correspondence where who is writing matters.
[03] $ I lost my secret key. Can the messages be recovered? ▸
> No. The secret key is the only way to read them, and we never had it. If you would rather not lose a key, derive it from a passphrase: then remembering the phrase is enough. But the salt is the same for everyone in that case, otherwise the key would not reproduce — which means a short phrase is the same as handing the key over.
[04] $ The public key was sent to me in the same chat. Is that enough? ▸
> No. Whoever can substitute a message can substitute the key inside it — and then you encrypt for them. The key must come from somewhere it is already confirmed another way: the recipient’s website, a channel’s pinned message, a business card. This is not nitpicking but the one weak spot of the scheme.
[05] $ Do you store keys or messages? ▸
> No. The page makes not a single network request while it works — everything is computed in this tab. We see neither keys, nor texts, nor ciphertexts.