Skip navigation
industry news

CryptoCat & The Practical Case for Implementing Forward Secrecy

Last week it was shown that CryptoCat's implementation of cryptography has been flawed for the past two years. The risk to communicating parties could range from low risk to serious trouble, depending on which version of CryptoCat they were using. The most important thing to note is that the risks exist due to crucial issues in the utilization of cryptography standards—standards that should have effectively guaranteed privacy of communications.

A somewhat bright light in this story is that the actual encrypted communications were being sent over SSL. This means that if an attacker was eavesdropping on communications, they wouldn’t have been able to do any more than record the SSL-encrypted transmissions and store them. The reality here is that, without the SSL private key that was used to transmit the data, the encrypted packet captures would be useless. What that also means, though, is that if the SSL private key was compromised the data actually may not be secure.

Luckily, there is a way for SSL to function so that even with the private key, previously recorded communications are unable to be decrypted without the SSL session key for that transmission. This idea is called Forward Secrecy. By using certain cipher suites (such as DHE-RSA-AES128-SHA), the session keys themselves are protected even if the private key for the SSL certificate handling the communications is compromised and a packet capture of a transmission is taken.

Frustratingly enough, this topic is addressed in the previously noted blogpost from the CryptoCat team stating, "We should also note that our SSL setup has implemented forward secrecy since the past couple of weeks." This, unfortunately, means that the worst-case scenario of an attacker getting both a packet capture of SSL communications and the private key could indeed decrypt the communications (with varying levels of ease) for nearly two years of conversations.

It's worth noting that there have been a few posts about Forward Secrecy lately. These include both how to deploy it and being wary of messing up such a deployment. Like any cryptography implementation, there are a number of scenarios that could result in mitigating the benefits you had in mind to gain from such an effort. This can quickly lead to a false sense of security. While the CryptoCat scenario may be a very specific look at the direct benefits of Forward Secrecy, it’s important to keep in mind how central this is to broader cryptography discussions.

There are real-world consequences for getting cryptography wrong in your software. For most, those consequences may lead to an easily crackable password hash. For CryptoCat, that failure has the potential to lead to the arrest or murder of those who were fighting for freedom.

While the hope remains that the CryptoCat SSL private key is indeed safe, the number of steps away from total compromise are entirely too close for comfort. When your users are political dissidents, journalists in harm’s way, and leaders in process of overthrowing a regime, getting cryptography so astoundingly wrong isn’t a situation to just be patched, but a time to consider who we trust to handle our safety and secrets.