Herman's Send tool
HorusPass Send is another find while exploring Bearblog.
Herman Martinus built BearBlog, and has an inspiring projects page. There's something energizing watching someone just... keep putting cool things into the world. And Send isn't just one of those things, it's also a thoughtful application of cryptography!
Here's a little tool that lets you share a secret — a password, an API key, a confession of love — that can only be read once. After the recipient opens it, it's gone. Poof.
The server generates two tokens. Token A goes in the URL you share as a query parameter. Token B stays on the server. You need both to encrypt or decrypt. When the recipient clicks the link, the server hands over Token B — then deletes it. The browser decrypts the message.
It's kind of the same as writing your password on a sheet of paper, but ripping it in half and hiding both halves in different places. If someone finds one, you're still safe.
The thing here is that the server is writing the password, not you, and giving you one half. You have to trust it deleted the half it gave you, right?
Not quite.
Here's what you're not trusting: that the server saw your encrypted message.
Even if the server has the keys, it doesn't have the lockbox. The ciphertext passes from sender to recipient in the URL fragment: everything after the #. Browsers don't send those fragments to servers.
Why not generate both tokens in the browser and send one to the server? Then the server never sees the full key. That opens up another problem: the server would be storing data submitted by users, which opens it up to abuse — people uploading arbitrary content, not just random tokens. This could be even abused by bots, and Herman already has enough fun messing with them. Why invite more trouble.
There's more sophisticated cryptography. You can generate keys that are born split — where no single party ever holds the complete key, even at creation. The browser and server could each contribute randomness in a process cryptographers call "ceremonies" because they like to sound mysterious. Both sides random inputs combine in a way that produces key shares, and neither would ever see the full key. This is the world of threshold cryptography and multi-party computing. Pretty interesting to learn, but also more complex to build.
The beautiful thing about Herman's design: none of that is really necessary, since the ciphertext never hits the server anyway.
I wrote before about Ronan's commit-reveal games and the question he keeps asking: "Why do I need anything else?" HorusPass is the same insight.
What I really like: Herman's explanation on the site is fast and clear. Four bullet points and you understand what's happening. No jargon, no mystique. He wants you to see how it works.
That's a breath of fresh air for me. And it's the same ethos as the tool itself — serving a clear need using regular cryptographic primitives in a practical way. Just like writing your password across two sheets of paper.
The smart way is often the simple way.