Fingerprints, seals, and secret recipes: the cryptography behind Chirp

Words like "cryptographically signed," "hashed," and "RS256" do a lot of work in security writing, and they tend to either get waved past or buried in math. They need to be neither. Almost everything Chirp does rests on three small, old, well-understood tools, and each has a plain-English version you can hold in your head. This post explains all three, with no math, and points at where Chirp uses each. None of them are Chirp's invention; what matters is what each one does and why it's the right tool for the job.

1. The one-way fingerprint

Imagine a machine that takes anything — a word, a whole book — and stamps out a short, fixed-size smudge, like a fingerprint. Two rules make it useful:

• The same input always produces the same fingerprint.
• You cannot run it backwards. From the fingerprint there is no way to reconstruct the input, and changing even one letter of the input produces a completely different fingerprint.

So a fingerprint identifies something without revealing it. The technical name is a hash; the one Chirp uses is SHA-256.

Where Chirp uses it:

• Your different name at every app. Chirp takes the app's id and your account's id, runs them through the fingerprint machine together, and the result is your identifier at that app. You can't run it backwards, so the app can't recover your real account id; a different app produces a different fingerprint, so no two apps can match you up. (That's the whole pairwise subjects idea.)
• Proving you hold a secret without sending it. When your app begins a sign-in, it invents a random secret, sends only the secret's fingerprint, and reveals the secret itself one step later. Chirp fingerprints what it's shown and checks the two match. Anyone who intercepted the first message saw only a fingerprint, which they can't run backwards.

How firm is "can't run it backwards"? Not "nobody's tried" — guessing the input behind a SHA-256 fingerprint would take every computer on earth far longer than the universe has existed. That is the sense in which it is one-way.

2. The sealed signature

This is the wax seal from "what 'Sign in with…' does", and it's worth saying exactly why it works. A signature uses a pair of matched keys:

• a private key — like a unique signet ring — that only the issuer holds, and that never leaves them;
• a public key — like a photograph of the genuine seal — that the issuer hands out to everyone.

The two halves are matched but not interchangeable. With the private ring you can stamp a document. With the public photo you can check that a stamp is genuine — but you cannot use the photo to make one. Producing the seal is private; checking it is public.

That asymmetry is the most important idea in this post. It lets the issuer prove "I, and only I, produced this" to people it has never met, without sharing any secret with them.

Where Chirp uses it: every token Chirp issues is signed this way. When you sign in, your app receives a small signed statement — "this is the same person, present just now." Chirp stamps it with its private key; your app checks the stamp against Chirp's public key, published at a fixed web address. A statement that doesn't check out is discarded. Forging one would mean holding the private key, which never leaves Chirp; verifying one needs only the public key, which anyone can fetch. The technical name for the exact scheme is RS256.

3. The secret-recipe fingerprint

Take the fingerprint machine from the first section, but require a secret ingredient mixed in before it stamps. Now the result isn't just "this message" — it's "this message, stamped by someone who knows the secret." Anyone can see the result, but only someone with the secret recipe can produce a matching one or confirm a given one is real.

This is a different job from signing. A signature proves something to anyone, with a public check. The secret-recipe fingerprint proves something between two parties who already share a secret — smaller and faster, and useful exactly when both sides know the secret already. The technical name is HMAC.

Where Chirp uses it: proving a notification really came from Chirp. When Chirp tells your server that something happened, it stamps the message with a secret only the two of you share. Your server re-stamps the message and checks the result matches, so a forged notification from anyone else fails the check.

What these tools do, and don't

The honesty is in the narrowness. Each does one well-defined thing:

• A fingerprint hides an input and reveals any change to it. It does not encrypt — it's a one-way smudge, not a locked box you can reopen.
• A signature proves who produced something and that it wasn't altered. It does not hide the contents — a signed token is readable by anyone; the signature only vouches for it.
• A secret-recipe fingerprint proves a message is authentic between two parties. It is only as private as the shared secret.

None of these makes a system "secure" on its own. They are the parts. Using them correctly — checking the signature every time, never sending the secret, keeping the private key private — is the work. The thing worth taking away is that none of it is magic: three small, old, well-understood tools, each doing one plain thing, are what sit underneath every reassuring word on a security page.