You are using an unsupported browser. Please update your browser to the latest version on or before July 31, 2020.

How do ZRTP’s key continuity features compare with SSH?

The key continuity features of ZRTP are analogous to those provided by SSH, but they differ in one respect. SSH caches public signature keys public signature keys that never change, and uses a permanent private signature key that must be guarded from disclosure. If someone steals your SSH private signature key, they can impersonate you in all future sessions and mount a successful man-in-the-middle (MiTM) attack any time they want.
ZRTP caches symmetric key material that is mixed into the next session’s secret session key, which changes with each session. If someone steals your ZRTP shared secret cache, they only get one chance to mount a MiTM attack, in the very next session. If they miss that chance, the retained shared secret is refreshed with a new value, and the window of vulnerability heals itself, which means they are locked out of any future opportunities to mount a MiTM attack. This gives ZRTP a self-healing feature if any cached key material is compromised.
A MiTM attacker must always be in the media path. This presents operational difficulties for the attacker in many VoIP usage scenarios, because being in the media path for every call is often harder than being in the signaling path. This creates coverage gaps in the attacker’s opportunities to mount a MiTM attack. ZRTP’s self-healing key continuity features are better than SSH at exploiting any temporary gaps in MiTM attack coverage. Thus, ZRTP quickly recovers from any disclosure of cached key material. 
In systems that use a persistant private signature key, such as SSH, the stored signature key is usually protected from disclosure by encryption that requires a user-supplied high-entropy passphrase. This arrangement may be acceptable for a diligent user with a desktop computer sitting in an office with a full ASCII keyboard. But it would be prohibitively inconvenient and unsafe to type a high-entropy passphrase on a mobile phone’s numeric keypad while driving a car. Users will reject any scheme that requires the use of a passphrase on such a platform, which means mobile phones carry an elevated risk of compromise of stored key material, and thus would especially benefit from the self-healing aspects of ZRTP’s key continuity features. 
The infamous Debian OpenSSL weak key vulnerability (discovered and patched in May 2008) offers a real-world example of why ZRTP’s self-healing scheme is a good way to do key continuity. The Debian bug resulted in the production of a lot of weak SSH keys, which continued to compromise security even after the bug had been patched. In contrast, ZRTP’s key continuity scheme adds new entropy to the cached key material with every call, so old deficiencies in entropy are washed away with each new session.
There is one more benefit to ZRTP’s form of key continuity. It confers a measure of immunity from any future breakthroughs in quantum computing that may undermine the strength of public key algorithms such as Diffie-Hellman. I think the fears about quantum computers are overblown, because of severe practical difficulties in building effective quantum computers. Especially considering the Diffie-Hellman key sizes used in this protocol. Nonetheless, let’s indulge in wild fearmongering and assume that someday quantum computers of the required complexity can somehow be built. Despite this, symmetric key algorithms with key lengths of 256 bits remain secure against quantum computers. This means ZRTP’s symmetric key continuity can save the day, provided the wiretapper was not present in the first call. That’s because the wiretapper does not know the shared secret inherited from the first call that will be mixed into the session keys of subsequent calls. In which case he cannot compute the new session key, even if he can break Diffie-Hellman.
This also implies that you can use AES-256 with 3072-bit Diffie-Hellman keys, and still get the full benefit of the strength of the 256-bit AES key. This would seem to be at variance with NIST guidelines which recommend using AES-128 with DH-3072, because the work factor for breaking both of them is about equal. But if ZRTP can mix in an additional 256 bits of shared secret entropy from earlier sessions when computing the new session key, the strength of the result can exceed the strength of DH-3072. This assumes the wiretapper was not able to observe the first session.

  • 69
  • 12-Jun-2017