ZRTP was published as RFC 6189 in 2011, credited to Phil Zimmermann (the author of PGP), Jon Callas, and Alan Johnston. The problem it set out to solve is specific: two people want an encrypted phone call, they may never have exchanged keys before, and they do not want to trust a company, a certificate authority, or a directory server to introduce them. The only shared channel they are guaranteed to have is the call itself, plus their own ability to recognize each other's voices.
That last detail is the whole trick. ZRTP uses the voice channel as the verification channel, and it uses the human as the trust anchor.
What ZRTP actually encrypts, and what SRTP does
It helps to separate two layers. The media itself (the digitized audio packets) is encrypted with SRTP, the Secure Real-time Transport Protocol, typically using AES in counter mode with an HMAC for integrity. SRTP is fast and well understood, but on its own it has no answer for the hardest question: where does the key come from?
ZRTP is the key agreement layer that answers that question. When a call starts, the two endpoints run a Diffie-Hellman exchange inside the RTP stream, agree on a shared secret, and derive the SRTP session keys from it. ZRTP handles the negotiation; SRTP carries the protected audio. Neither the carrier, nor a signaling server, nor a certificate issuer ever sees the key.
SRTP encrypts the audio packets. ZRTP is how the two phones agree on the SRTP key without any pre-shared secret or public-key infrastructure. You can run SRTP with keys handed down by a server; ZRTP exists so you do not have to.
The short authentication string
A raw Diffie-Hellman exchange is vulnerable to a machine in the middle. An attacker who can intercept and relay the packets can run one exchange with each party and sit between two separately encrypted legs, reading everything. Certificate systems defend against this by having a trusted authority sign the keys. ZRTP has no authority, so it does something else.
After the key exchange, each phone computes a hash over the negotiated material and displays a short string derived from it, usually two pronounceable words or a few characters. This is the Short Authentication String, or SAS. The two people read it to each other over the call they have just established.
If both phones show the same SAS, no attacker sat in the middle. A machine in the middle would have run two different key exchanges, producing two different strings, and could not force them to match without breaking the underlying hash. The security property in one sentence
Because the people are already talking, they also get voice recognition for free. An attacker who relays the audio can substitute their own SAS words, but they cannot fake the sound of a familiar voice reading them. This is why ZRTP is described as protecting against a man in the middle even without any prior key exchange: the human closes the gap that the math leaves open.
Key continuity: trust that grows across calls
Reading the SAS aloud on every single call would be tedious, so ZRTP adds key continuity. After a verified call, each phone caches a shared secret. On the next call, that cached secret is mixed into the new key derivation. If it still matches, the phones know they are talking to the same endpoint as last time, and the SAS does not need to be re-verified.
This is the same trust-on-first-use idea that underpins SSH host keys and the TOFU verification model. You accept a small risk on the very first contact, verify it once with the SAS, and every call afterward is anchored to that first verified exchange. If the cached secret ever fails to match, the phone warns you, which is exactly the signal you want if someone has swapped in a new endpoint.
What ZRTP does not protect
ZRTP secures the contents of the call. It does not hide the fact that a call happened. Your carrier, or anyone watching the network, can still see that two endpoints exchanged real-time media, how long the call lasted, and how much data moved. That is metadata, and it lives in the same category as the metadata exposure that affects nearly every communication system.
- Contents: protected by SRTP with keys from ZRTP. Strong.
- Endpoint authentication: handled by the SAS plus key continuity, and it depends on the humans actually reading the string the first time.
- Metadata: not addressed. Call timing, duration, and endpoint addresses remain visible to the network.
- A compromised device: outside the model entirely. ZRTP protects the channel, not a phone with malware on it.
Where you have already used it
ZRTP is not a museum piece. It shipped in Zimmermann's own Zfone, in Silent Circle's early products, and it is implemented in open-source stacks including Jitsi, Linphone, and the GNU ZRTP libraries. The design also influenced how later systems think about human-verifiable key confirmation. The safety-number comparison in modern secure messengers is a direct descendant of the SAS idea: derive a short value from the negotiated keys, and let two people confirm it out of band.
The reason to understand ZRTP in 2026 is not to deploy it tomorrow. It is that the pattern (agree on a key with math, then have a human confirm a short derived value) is the most honest way to bootstrap trust when you refuse to rely on a central authority. That pattern shows up anywhere a system wants end-to-end verification without a gatekeeper.
ZRTP compared to the alternatives
| Approach | Trust anchor | Trade-off |
|---|---|---|
| ZRTP | The two humans reading the SAS | No servers or certificates, but the first call needs a spoken verification to be fully protected |
| SDES / server-keyed SRTP | The signaling server | Simple to deploy, but the server sees or sets the keys, so it is a single point of compromise |
| DTLS-SRTP with certificates | A certificate fingerprint carried in signaling | Standard in WebRTC, but the fingerprint is only as trustworthy as the signaling path that delivered it |
None of these is universally correct. The right choice depends on who you are willing to trust and what you are defending against. ZRTP's contribution is proving that you can get strong endpoint verification with no infrastructure at all, provided the two people are willing to spend five seconds confirming two words.
Where Haven fits
Haven is encrypted email and group chat rather than a voice product, so we do not ship ZRTP. We bring it up because the principle behind it runs through our own design: verification should map to something a human can actually check, and it should never quietly depend on a party you did not choose to trust. Our group messaging uses MLS (RFC 9420) and our email uses PGP, and in both cases the goal is the same one Zimmermann was chasing in 2011. Give people a way to confirm who they are really talking to, without asking them to trust a company to vouch for it.