The ZRTP protocol has some nice cryptographic features lacking in many other approaches to VoIP encryption. Although it uses a public key algorithm, it avoids the complexity of a public key infrastructure (PKI). In fact, it does not use persistent public keys at all. It uses ephemeral Diffie-Hellman with hash commitment, and allows the detection of man-in-the-middle (MiTM) attacks by displaying a short authentication string for the users to verbally compare over the phone. It has perfect forward secrecy, meaning the keys are destroyed at the end of the call, which precludes retroactively compromising the call by future disclosures of key material. But even if the users are too lazy to bother with short authentication strings, we still get fairly decent authentication against a MiTM attack, based on a form of key continuity. It does this by caching some key material to use in the next call, to be mixed in with the next call’s DH shared secret, giving it key continuity properties analogous to certificate authorities, All this is done without reliance on a PKI, key certification, trust models, or key management complexity that bedevils the email encryption world. It also does not rely on SIP signaling for the key management, and in fact does not rely on any servers at all. It performs its key agreements and key management in a purely peer-to-peer manner over the RTP packet stream. And it supports opportunistic encryption by auto-sensing if the other VoIP client supports ZRTP. ZRTP doesn’t need a PKI, and there are good reasons why it’s a mistake to require a PKI for secure VoIP. Plus, there have been a growing number of spectacular security failures of traditional PKIs. Nonetheless, ZRTP can use a PKI if you already have one up and running. Follow this link for how this is done.