Verbal Cryptography: Keys You Can Say Out Loud
Authentication With Nothing to Steal — a stolen password works for whoever stole it, a stolen token for whoever holds it. The interesting factor is the one that can't be copied or handed off, because answering it requires actually doing the transformation in your head, every time.
The problem: possession-based factors are copyable, one way or another
Most authentication factors ultimately reduce to possession of a thing: a password (a string you know), a hardware key (an object you hold), a one-time code (a number your phone shows you). All three share a weakness that has nothing to do with how strong the underlying cryptography is — the output of the factor, once produced, is just data. A password can be phished and replayed. A one-time code can be relayed in real time by a proxy attacker faster than the user can notice anything wrong. Even a hardware key’s signature, once it exists, is a blob someone else’s script can potentially resubmit if the session around it is compromised. The common thread: the factor produces a fixed artifact, and a fixed artifact can always be captured and reused by something that isn’t the person who produced it.
The approach: make correctness depend on private state a copy can’t carry
The interesting alternative is a challenge-response scheme where the response is not a static secret but the result of a personal transformation applied fresh, every time, to a challenge the system displays at the moment of the attempt. The user holds a private selection method — which pieces of a displayed prompt they combine, and how — that lives only in their memory, never transmitted, never stored anywhere in reproducible form. The system shows a challenge that changes every time (so yesterday’s correct answer is worthless today), and the user has to actually perform the transformation in their head to produce the right response.
This is meaningfully different from “type your password” in one specific way: there is no static artifact anywhere in the system — not on the user’s device, not on the server — whose theft alone lets an attacker reproduce a valid response to the next challenge. Stealing yesterday’s correct answer teaches an attacker nothing about tomorrow’s, because tomorrow’s challenge is different and the transformation has to be redone from a method that was never written down anywhere a copy could be taken from. The same discipline shows up in how reckon derives its own signing keys — see Inside the custody chain for the mechanism where a key is derived fresh from a seed and never itself stored, copied, or transmitted, so possessing an old signature doesn’t hand you the ability to produce the next one.
This isn’t a new idea in cryptographic authentication — it’s the same design goal behind a Short Authentication String (SAS), the property ZRTP uses to let two people confirm a key exchange happened with each other and not a man-in-the-middle by comparing a short, human-checkable value derived fresh each session. Vaudenay’s original construction for authenticating over insecure channels using short strings and the follow-up SAS-based authenticated key agreement by Pasini and Vaudenay are the formal ancestors of this pattern: the short string is only useful once, tied to a specific exchange, and worthless if replayed against a different one.
The result: a factor that resists both theft and relay
Two attacker models fall out of this cleanly:
- Database compromise is survivable. Because the personal method never leaves the user and is never stored server-side in a form that would let the server reconstruct it, stealing the server’s records does not hand an attacker the ability to pass future challenges.
- Real-time relay is much harder. A classic relay attack works by forwarding a challenge to the real user and forwarding their real response back — but that requires the real user to actually be present and cooperating in the moment, turning a silent, automatable attack into one that needs a live human accomplice for every single attempt.
Neither property depends on the transformation being mathematically exotic. It depends on the transformation living somewhere a copy operation cannot reach: a person’s own head, re-applied fresh each time, rather than a value that, once produced, is just bytes.
None of this is free, and the honest caveat is usability. Schröder et al.’s study of real-world secure-messaging authentication ceremonies found that users routinely believe they’ve verified a key exchange correctly when they haven’t — the ceremony fails silently from the user’s point of view. Vaziripour et al.’s usability study of authentication ceremonies found that even correctly completed ceremonies read to users as undesirably long. A factor that lives entirely in someone’s head is only as strong as their willingness to actually do the mental work every time — which is a human-factors problem, not a cryptographic one, and worth naming rather than assuming away.
The takeaway
The strongest authentication factors aren’t the ones with the most entropy — they’re the ones that can’t be separated from the party who’s supposed to hold them. A password can be copied because it’s just a string. A physical key can be handed over because it’s just an object. A transformation performed fresh in someone’s head, against a challenge that’s different every time, is the rare factor that resists both.