Secure Protocols in a Hostile World

It is Tuesday afternoon of CHES in Saint Malo and I will be blogging the only invited talk of the conference entitled "Secure Protocols in a Hostile World" given by Matthew Green from John Hopkins University.

The talk begins with a slide entitled "Cryptography is a solved problem" and contains lots of quotes such as "Crypto is the strongest link in the chain" and "Why would you focus on making the strongest part of a system stronger". It is explained that this is wrong and the remainder of the talk is justifying why these people's views aren't correct and that we should still care about creating new crypto. Crypto can be seen as being split into the following five parts:

1. Algorithms
2. Protocol Design
3. Implementation
4. Library API Design
5. Deployment and Correct Usage

We as cryptographers spend most of our time working on the first point and we are very good at it but the further down the list you go the more unsolved the problems are. Taking implementation as an example there are schemes (such as ElGamal) which are secure because they come with proofs of security but implementing them is hard and if not done carefully leads to sidechannels which allows the scheme to be broken.

Why does it matter that we focus on the first point and leave the rest to others? Well Heartbleed and FREAK to name two reasons why this matters and is becoming more of an issue. In 2015 we seem very good at designing new strong crypto but have still not got the hang of deploying strong crypto out into the real world. We will now look at a case study.

SSL/TLS

SSL has been described as "The most important security protocol on the Internet", however recently it has had its own share of troubles, including; Heartbleed, Lucky13, FREAK, CRIME, BEAST and RC4 (well unlike the rest RC4 isn't an attack but has caused its fair share of trouble recently).

So below I will give a few examples of issues with SSL/TLS;

• CBC with MAC then Encrypt
• Bad use of IVs
• Compression
• RC4 (I think my favourite quote of the conference so far has been "When RC4 is the solution, you need a better problem")

All of these problems are well known - I mean MAC then Encrypt not (always) being secure is taught in undergraduate crypto courses so what is it doing in TLS?! The answer is communication, the people doing the implementation are not cryptographers so don't always know about these things and cryptographers tend to be looking for the 'next big thing' instead of working within all five of the points above. To further emphasize the need for communication; when FREAK was released three TLS implementations had the exact same bug that allowed FREAK to happen. There is a clear disjoint here that needs to be resolved.

Another example was then given in the form of a downgrade attack from DHE to DHE_EXPLOIT and then solving the corresponding discrete logarithm problem. This is known as LogJam and will appear at CCS15 so I won't go into detail here but it is certainly worth looking into (and was fixed in browsers only a couple of weeks ago).

Conclusion

I am going to conclude using the same bullet points that Matthew used on his own slides as I think this hits the nail on the head.

Cryptography is hard

Cryptographers fail to push best practices to engineers

Engineers fail to pull best practices from us or from the literature

Cryptography is becoming more complex

It has got to the point this process can no longer be tolerated and something needs to be done about it