Intro
After LogJam vulnerability was published, and then the WeakDH paper (Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice) was published, we were asked a few times: since Secure Session uses Diffie-Hellman key negotiation, is prone to the same attacks?
We wrote this small note to explain why we are safe from such attacks, and how generally decisions about such important security features are being done for the open source Themis crypto library.
The 2-part problem with WeakDH
Part 1. SSL and some other protocols have algorithm selection phase, which happens over unauthenticated channel, and Man-in-the-Middle can effectively degrade key negotiation algorithm to DH-512 (512-bit group Diffie-Hellman). Moreover, it can be done to Diffie-Hellman with 1024-bit groups length.

Part 2. DH-512 itself is still rather complicated to crack, so protocol designers allowed some computationally expensive parts of specified groups to be pre-computed and stored. By pre-computing the same groups, paper authors were able to compromise key exchange in minutes.
Happy anonymous hackers, enjoying Log Jamming in the warm sun.
Although it might like a rare theoretical threat from the first sight, up to 5% of Internet’s servers are vulnerable, and up to 80% of them use the same 512bit group, minimising the attack length even further.
What we do in Secure Session
NOTE: To get general impression of how Secure Session works, read a bit through this document and this scheme
In Secure Session, we don’t do algorithm negotiation, as we believe this is exactly the case where flexibility makes stability wiggly, and backwards compatibility leads to vulnerabilities and threats. We use ECCDH P-256 and expect other Secure Session application to do the same.
We use ECDH, Elliptic-Curve based Diffie-Hellman key exchange, which does not rely on modular arithmetics of RSA (as in regular Diffie-Hellman). Algorithms for cracking regular Diffie-Hellman exchanges don’t work with ECDH.
Pre-computer group parameters are not applicable to Elliptic Cryptraphy
Why we do that
We, as designers of a security library, value secure design much more than flexibility, since so many troubles are introduced through this desire to serve heterogenous environments. We believe that in the world of rapid online updates of software, compatibility is a question of correct application architecture: ability to carry adjustable screw-wrenches allows you to avoid carrying a bag with wrenches of all sizes, so why should a security component of application carry all kinds of legacy vulnerable algorithms?
We feel deep responsibility not only for data in our own applications, but for design choices that we project through Themis, and enforcing usage of only the best modern cryptography is one of our goals.
P.S. If you're looking for new ideas, this is the right place. If you're looking to implement security, apply for our Customer Success Team. If you're looking for ready-made solutions, consider looking into Themis, Acra, Hermes, or Toughbase.
