Making sure crypto remains insecure [pdf]
This is a fun slide deck, but if you'll forgive me for sucking some of the mystique out of it: it's just a reframing of DJB's hobby horses:<p>* The group that standardized AES rejected cache timing as a viable attack vector: <a href="http://cr.yp.to/antiforgery/cachetiming-20050414.pdf" rel="nofollow">http://cr.yp.to/antiforgery/cachetiming-20050414.pdf</a> --- more generally, that constant-time algorithms and constructions (a feature of virtually all of Bernstein's work for the last 15+ years) aren't taken seriously in industry. Also helpful to know: there's a defensible argument that Bernstein more or less started AES cache timing research.<p>* Side-channel attacks weren't taken seriously by TLS, and Bernstein is affiliated with one of the research groups that found a TLS side-channel attack: <a href="http://www.isg.rhul.ac.uk/tls/Lucky13.html" rel="nofollow">http://www.isg.rhul.ac.uk/tls/Lucky13.html</a><p>* Application-layer randomness is a bad idea, and, like Nacl does, everyone should just use a single, carefully audit kernel RNG: <a href="http://blog.cr.yp.to/20140205-entropy.html" rel="nofollow">http://blog.cr.yp.to/20140205-entropy.html</a><p>* Protocols and constructions should be designed to minimize dependence on randomness, the way DJB's EdDSA does: <a href="http://ed25519.cr.yp.to/ed25519-20110926.pdf" rel="nofollow">http://ed25519.cr.yp.to/ed25519-20110926.pdf</a><p>* Crypto performance is both not taken seriously as a research goal and an excuse for the deployment of terrible cryptography. This isn't so much a hobby horse of DJB's as it is <i>his entire research career</i>: <a href="http://cr.yp.to/cv/research-net-20070115.pdf" rel="nofollow">http://cr.yp.to/cv/research-net-20070115.pdf</a><p>* DNSSEC, with its core design goals of "sign-only", "sign offline", and "sign from the root down" is a terrible idea. A sane design would look more like DNSCurve: <a href="http://dnscurve.org/" rel="nofollow">http://dnscurve.org/</a> (helps also to know that DJB has a longstanding feud with both the design team for BIND, the flagship DNSSEC implementation, and with Namedroppers, the IETF DNS standardization list).<p>Unsurprisingly, considering the source, these are all really great important ideas. Bernstein is one of my heroes, and I'm certainly not trying to take him down a peg here. I just thought it might be interesting for people to know that this deck is less a revelation about cryptography than it is a survey of DJB's research over the last 15 years.<p>I'm surprised he didn't take more time on RC4, which he was closely involved with breaking. The story about how something as dazzlingly broken as RC4 could have gotten so entrenched in the industry is much more interesting than the story about how AES was standardized despite its performance relying so much on table lookups.