A secret you never send
A Socratic walk-through of a secret you never send — reasoned out one step at a time, not lectured.
The question we started with
THE QUESTION #How do you prove you know something without ever transmitting it?
A password is a strange arrangement when you look at it directly. To prove you know it, you hand it over — to the server, and to every piece of software between you and it. The proof consists of giving away the very thing that made you special, and you must do it again on every login, to every site.
Which invites a question that sounds impossible on first hearing. Could you convince someone you know a secret while never letting them, or anyone listening, learn it? And if you could, what would the secret have to be like?
Reasoning it through
REASONING #Start with what the verifier needs. It must be able to distinguish someone who knows the secret from someone who does not. So it needs something to check against. If that something is the secret, we have gained nothing — the server holds it, and a breach spills it.
So the requirement sharpens: the verifier must hold something derived from the secret that is enough to check an answer but not enough to produce one. Is such a thing possible? It is, and it is the entire content of asymmetry. Generate a pair of related values such that one can produce signatures and the other can only verify them, and such that deriving the first from the second is computationally out of reach. Now the verifier can be handed the public half openly, and a leak of everything it stores lets an attacker verify logins, which is useless to them.
That solves half of it. What have we not solved? Consider what the prover actually sends. If it is a fixed value — "here is my signature" — then anyone who overhears it can send the same bytes tomorrow. A constant proof is just a password with extra steps.
So the proof must be about something that cannot be known in advance. Let the verifier pick a fresh, unpredictable value and demand a signature over that. Now an eavesdropper holds a signature over a challenge that will never be issued again, which is worth nothing. The secret was never transmitted, and the transcript is not reusable.
There is one gap left, and it is the subtle one. Suppose you connect to a malicious server. It hands you a challenge — but the challenge was not its own. It asked a bank for one first and passed it along. You sign it, and your signature is relayed to the bank, which admits the attacker. Freshness stopped replay across time; it did nothing about relay across parties.
The fix is to make the signed material name the conversation. In SSH public-key authentication, the client does not sign a bare nonce: it signs a structure containing the session identifier derived from the key exchange, along with the user name, the service, and the public key being offered. A signature made inside one session is meaningless in any other. WebAuthn does the same job with different content — the signed data covers the challenge, the identifier of the site, and a hash of client data that includes the origin the browser actually connected to.
One piece of honesty about the name. This is not a zero-knowledge proof in the cryptographer's technical sense; a signature does reveal something, namely a valid signature. It is fine precisely because that revelation is not invertible and does not help forge another. If you genuinely want to prove knowledge of a low-entropy secret like a human-chosen password without sending it, that is a different family of protocols — password-authenticated key exchange, such as SRP or OPAQUE — built to deny an eavesdropper even the chance to guess offline.
The analogy
THE ANALOGY #Think of a signet ring. Rather than showing anyone the ring, you ask them to write a letter — their words, chosen by them, this morning — and you press your seal into wax on it. They compare the impression with the seal they already have on file. They never handle the ring, and the sealed letter proves nothing about any other letter, because they chose the words themselves.
a wax impression really does disclose the seal's shape well enough for a patient forger to carve a copy, whereas a signature discloses nothing that helps produce the next one — and the analogy also hides the relay problem, since a courier could carry your sealed letter to a third party who wanted that exact text signed, which is why the real protocol makes the signed material name the conversation it belongs to.
Clarifying the model
THE MODEL #The refinement that connects the pieces: three properties are doing three separate jobs, and dropping any one breaks the scheme in a different way. Asymmetry means the verifier's stored copy is not a secret. Freshness means the transcript cannot be replayed later. Binding means the proof cannot be carried sideways into a different session or site. A design with the first two and not the third is exactly the relay attack above, and it is not hypothetical.
The misconception to correct is that this removes the need to protect anything. It does not; it moves what must be protected from a shared secret held by many parties to a private key held by one. That is a large improvement — there is no longer a database whose theft compromises every account, and no per-site reuse — but the key file on your laptop is now the thing that matters, which is the argument for keeping it in hardware that will sign on request and never export it.
And a limit worth stating plainly: none of this establishes who you are. The verifier must already hold the right public key, and how it came to hold it is a separate problem — accepted on first connection and trusted thereafter in the SSH habit, or bound during an enrolment ceremony in WebAuthn. The proof is only as meaningful as that registration was.
A picture of it
THE PICTURE #How to readRead downward and watch what crosses the gap between the two lifelines. The private key never appears on any arrow — the only things that travel are a claim, a challenge, and a signature. The self-arrow on the client is where the secret is used without leaving; the self-arrow on the server is where verification happens using public data alone. The reason the transcript is safe to overhear is in the final note: the challenge on the second line will never be issued again, and the session context folded in on the third line is what keeps the signature from being carried to a different server.
What became clearer
WHAT CLEARED #Proving knowledge without disclosure needs three separate things, not one clever trick: an asymmetry so the verifier can check without being able to produce, a fresh challenge so the proof cannot be replayed, and a binding to the session so it cannot be relayed elsewhere. What you gain is that the verifier's entire database is public information. What you take on is the safekeeping of one private key — and the separate, unglamorous problem of making sure the right public key was registered in the first place.
Where to go next
ONWARD #- How password-authenticated key exchange proves knowledge of a weak secret while denying an offline guessing attack.
- What an SSH host key fingerprint actually commits you to, and why first-connection trust is the weakest link in the chain.
Key terms
TERMS #| Term | What it means |
|---|---|
| Challenge-response | a protocol in which the verifier issues an unpredictable value and the prover returns a response only the secret's holder could compute. |
| Nonce | a value used once, whose freshness is what makes a captured transcript useless later. |
| Public-key authentication | proving identity by signing with a private key that the verifier checks using the corresponding public key. |
| Relay attack | forwarding a legitimate proof to a different verifier, defeated by binding the signed material to the session and origin. |
Every term the collection defines is gathered in the glossary.