Securing a phone call has an awkward shape. The call is set up by signaling, the SIP or similar messages that route the two parties to each other, and those messages usually pass through servers you may not trust. Then the actual audio flows as a separate media stream. If you try to exchange keys through the signaling path, you are trusting whatever operates that path. ZRTP, published as RFC 6189 in 2011, sidesteps the problem by keying the media stream over the media stream itself.
Keys in the Media Path, Not the Signaling
Once the call connects and audio packets begin to flow, ZRTP runs a Diffie-Hellman key exchange inside that media channel. Each side generates an ephemeral key pair, they exchange public values, and each combines its own secret with the other's public value to compute a shared secret that an eavesdropper watching the packets cannot derive. From that secret they derive the keys used to encrypt the call with SRTP, the secure form of the real-time media protocol.
Because this happens in the media path, it does not matter whether the signaling servers are honest or even whether they support encryption at all. The two endpoints handle their own security end to end. There is no certificate to validate, no CA to trust, no account directory to consult. This is deliberately the opposite of the PKI model, and it removes the entire class of failures that comes with certificate authorities.
ZRTP performs an ephemeral Diffie-Hellman exchange over the audio stream to key the call, so the encryption depends only on the two phones, not on any server, certificate, or shared identity system.
Diffie-Hellman on its own has a well-known gap. It protects against a passive eavesdropper, but an active attacker who can sit between the two parties can run a separate exchange with each side and relay the audio, decrypting and re-encrypting in the middle. Neither endpoint would notice from the math alone. ZRTP needs a way to detect that man in the middle, and its solution is the memorable part.
The Short Authentication String
After the key exchange, each phone computes a Short Authentication String, or SAS, from a hash of the shared secret. It is short on purpose, typically a few characters or a pair of words, small enough to say out loud in a second or two. The display shows it to both callers.
The two people read the SAS to each other and check that it matches. Here is why that works. If there is no attacker, both sides computed the same shared secret and therefore the same SAS, and the strings match. If an attacker is relaying the call in the middle, they had to run two separate key exchanges, one with each party, producing two different shared secrets and therefore two different SAS values. The attacker cannot make both ends show the same string. When the callers compare and the strings disagree, the wiretap is exposed.
The attacker can intercept the packets and relay the audio, but they cannot force two independent Diffie-Hellman exchanges to produce the same short string. The moment the humans compare it, the interception either matches and reveals nothing wrong, or it does not and gives itself away. Why reading a few characters aloud is enough
The clever move is using the one channel an attacker cannot forge: the callers' own recognizable voices. A man in the middle can relay audio, but it cannot convincingly imitate your correspondent's voice reading the correct string in real time. The authentication rides on the medium the call already is. This is a voice-native version of the verify-the-fingerprint step that secure messengers ask you to do out of band.
Key Continuity: You Only Verify Once
Reading the SAS on every single call would be tedious, so ZRTP adds key continuity. After a successful call, each side caches a shared secret. On the next call between the same two parties, that cached secret is mixed into the new key derivation. If it still matches on both ends, the parties can trust the session without reading a fresh SAS, because a match confirms continuity with the previously verified call.
This gives a practical security posture that improves over time. The first call is verified by voice. Every later call silently confirms it is talking to the same peer as before. If the cached secret ever fails to match unexpectedly, that is a signal worth noticing, because it can indicate an interception attempt or a changed endpoint. The model resembles the way SSH remembers a host key after the first connection and warns you if it changes.
Forward Secrecy and What ZRTP Does Not Do
Because the Diffie-Hellman keys are ephemeral and discarded after the call, ZRTP provides forward secrecy. An adversary who records the encrypted audio and later seizes one of the phones cannot decrypt the stored call, because the keys that protected it no longer exist anywhere. This is a meaningful property for anyone whose recorded traffic might be scrutinized after the fact.
It is worth being precise about the boundaries, because no single protocol covers everything.
| Protects | Does not protect |
|---|---|
| The audio content of the call, end to end between the two phones. | The fact that a call happened, and the metadata about who called whom and when. |
| Against passive eavesdropping, with no CA or server involved. | Against a user who skips the SAS check on the first call with a stranger. |
| Past calls, through forward secrecy and discarded ephemeral keys. | A compromised endpoint device, which can capture audio before or after encryption. |
ZRTP has been implemented in tools including Zfone, Jitsi, and the Silent Phone application, and it remains a reference point for how to secure real-time media without infrastructure. Newer media-encryption work such as SFrame addresses group and conference scenarios that ZRTP's two-party design was never meant to cover. But for the specific problem of two people wanting a private call without trusting anyone in between, the ZRTP approach holds up: put the key exchange in the media, and let the humans close the loop with a few spoken characters.
The broader idea travels well beyond voice. When you cannot trust the infrastructure, you can often still build trust from something the attacker cannot fake, whether that is a recognizable voice on a call or a fingerprint verified out of band. The authentication does not have to come from a certificate. It has to come from something only the real parties share, and sometimes the simplest such thing is the sound of a familiar voice reading four characters.