Real-world Cryptography Workshop - Day 2
This is part two of the summary from the Day 1 of the workshop.
There were lots of good talks today at the workshop. I will highlight some of them:
Nadia Heninger from Microsoft Research discussed the dangers in bad key generation, along the same lines of the talk from yesterday by Jesse Walker (Intel). She showed that from a list of published certificates there are ~1% of completely hackable ones (meaning that you can find the private keys easily). These are either because they share a prime (and then factorizing is trivial) or they have the same public key. Interesting to hear that they noted the companies that have bad keys, but not all of them responded.
Ben Adida (Mozilla) gave an interesting talk about Persona. It is an open authentication platform that uses emails to authenticate, but unlike others (e.g., Facebook Connect), Persona does not learn the websites the user visits/authenticates. It is very easy to integrate for website authors (only JS is needed), and preserves users' anonymity, so it's pretty cool (not sure how well it will catch, though...perhaps when the Firefox phones will be out?).
Adam Langley's (Google) talk was very interesting, and he tried to inform researchers about the things they care most in the industry. Amongst these:
"Create a splash", meaning, make noise so that identified problems will be noticed by the community and not buried in a paper.
Notify the companies (let them know before publishing the problem, always publish code alongside with algorithms. As an example he gave AES, that has so many bad implementations out there, that it is almost impossible to know what each leaks.
If your algorithm runs slow now, using Moore's law and saying that it will run faster on future processors is nonsense, because in the future there will be more data that it will need to process. He summarized this by saying: "if it's crap now, it will be crap in the future".
Always design algorithms in constant time, to mitigate side-channel attacks.
Also provide designs on a budget - meaning, you can specify a very sophisticated algorithm, but these are commonly expensive to fully implement and deploy. In such cases, it is a good idea to also propose budgeted designs, that are perhaps a bit weaker, but are deployable.
The final talk by Eric Rescorla (RTFM) was mostly about deployment of TLS, showing the difficulty to deploy updates in the wild. He showed an interesting plot of the rate of certificate replacement given that they are known as broken, as opposed to timely replacement (due to expiration). It takes around 150 days to replace 50% of the certificate, in *both cases*. So people are not really worried about fixing stuff. IE7 is still common, with all its known bugs. TLS is still deployed with the older RC4 cyphers (also in Google, Amazon, Wells Fargo.
The talk gave an interesting perspective about real-world deployability of crypto innovations, and how difficult it is to actually push updates, even if they fix real security risks.
An interesting suggesting came from Ron Rivest (MIT) - "make crypto algorithms royalty free, unless they are found to be broken!" This is a very cool suggestion, which might drive companies to quickly change broken cryptos when they are broken (or otherwise, they need to start paying). I doubt anyone will ever do that, but it is cool nevertheless.















