<story><title>Making sure crypto remains insecure [pdf]</title><url>http://cr.yp.to/talks/2014.10.18/slides-djb-20141018-a4.pdf</url></story><parent_chain><item><author>tptacek</author><text>This is a fun slide deck, but if you&amp;#x27;ll forgive me for sucking some of the mystique out of it: it&amp;#x27;s just a reframing of DJB&amp;#x27;s hobby horses:&lt;p&gt;* The group that standardized AES rejected cache timing as a viable attack vector: &lt;a href=&quot;http://cr.yp.to/antiforgery/cachetiming-20050414.pdf&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;cr.yp.to&amp;#x2F;antiforgery&amp;#x2F;cachetiming-20050414.pdf&lt;/a&gt; --- more generally, that constant-time algorithms and constructions (a feature of virtually all of Bernstein&amp;#x27;s work for the last 15+ years) aren&amp;#x27;t taken seriously in industry. Also helpful to know: there&amp;#x27;s a defensible argument that Bernstein more or less started AES cache timing research.&lt;p&gt;* Side-channel attacks weren&amp;#x27;t taken seriously by TLS, and Bernstein is affiliated with one of the research groups that found a TLS side-channel attack: &lt;a href=&quot;http://www.isg.rhul.ac.uk/tls/Lucky13.html&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;www.isg.rhul.ac.uk&amp;#x2F;tls&amp;#x2F;Lucky13.html&lt;/a&gt;&lt;p&gt;* Application-layer randomness is a bad idea, and, like Nacl does, everyone should just use a single, carefully audit kernel RNG: &lt;a href=&quot;http://blog.cr.yp.to/20140205-entropy.html&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;blog.cr.yp.to&amp;#x2F;20140205-entropy.html&lt;/a&gt;&lt;p&gt;* Protocols and constructions should be designed to minimize dependence on randomness, the way DJB&amp;#x27;s EdDSA does: &lt;a href=&quot;http://ed25519.cr.yp.to/ed25519-20110926.pdf&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;ed25519.cr.yp.to&amp;#x2F;ed25519-20110926.pdf&lt;/a&gt;&lt;p&gt;* Crypto performance is both not taken seriously as a research goal and an excuse for the deployment of terrible cryptography. This isn&amp;#x27;t so much a hobby horse of DJB&amp;#x27;s as it is &lt;i&gt;his entire research career&lt;/i&gt;: &lt;a href=&quot;http://cr.yp.to/cv/research-net-20070115.pdf&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;cr.yp.to&amp;#x2F;cv&amp;#x2F;research-net-20070115.pdf&lt;/a&gt;&lt;p&gt;* DNSSEC, with its core design goals of &amp;quot;sign-only&amp;quot;, &amp;quot;sign offline&amp;quot;, and &amp;quot;sign from the root down&amp;quot; is a terrible idea. A sane design would look more like DNSCurve: &lt;a href=&quot;http://dnscurve.org/&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;dnscurve.org&amp;#x2F;&lt;/a&gt; (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).&lt;p&gt;Unsurprisingly, considering the source, these are all really great important ideas. Bernstein is one of my heroes, and I&amp;#x27;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&amp;#x27;s research over the last 15 years.&lt;p&gt;I&amp;#x27;m surprised he didn&amp;#x27;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.</text></item></parent_chain><comment><author>hendzen</author><text>&amp;quot;Protocols and constructions should be designed to minimize dependence on randomness, the way DJB&amp;#x27;s EdDSA does:&amp;quot;&lt;p&gt;I think a lot of the reason that ECDSA&amp;#x2F;DSA are so inelegant was that they were designed to get around the patent on the (quite elegant) Schnorr signature algorithm, which EdDSA is based on. Thankfully, the patent expired in 2008, so moving to better signature algorithms that don&amp;#x27;t rely on per-message randomness is a matter of institutional inertia at this point.</text></comment>
<story><title>Making sure crypto remains insecure [pdf]</title><url>http://cr.yp.to/talks/2014.10.18/slides-djb-20141018-a4.pdf</url></story><parent_chain><item><author>tptacek</author><text>This is a fun slide deck, but if you&amp;#x27;ll forgive me for sucking some of the mystique out of it: it&amp;#x27;s just a reframing of DJB&amp;#x27;s hobby horses:&lt;p&gt;* The group that standardized AES rejected cache timing as a viable attack vector: &lt;a href=&quot;http://cr.yp.to/antiforgery/cachetiming-20050414.pdf&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;cr.yp.to&amp;#x2F;antiforgery&amp;#x2F;cachetiming-20050414.pdf&lt;/a&gt; --- more generally, that constant-time algorithms and constructions (a feature of virtually all of Bernstein&amp;#x27;s work for the last 15+ years) aren&amp;#x27;t taken seriously in industry. Also helpful to know: there&amp;#x27;s a defensible argument that Bernstein more or less started AES cache timing research.&lt;p&gt;* Side-channel attacks weren&amp;#x27;t taken seriously by TLS, and Bernstein is affiliated with one of the research groups that found a TLS side-channel attack: &lt;a href=&quot;http://www.isg.rhul.ac.uk/tls/Lucky13.html&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;www.isg.rhul.ac.uk&amp;#x2F;tls&amp;#x2F;Lucky13.html&lt;/a&gt;&lt;p&gt;* Application-layer randomness is a bad idea, and, like Nacl does, everyone should just use a single, carefully audit kernel RNG: &lt;a href=&quot;http://blog.cr.yp.to/20140205-entropy.html&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;blog.cr.yp.to&amp;#x2F;20140205-entropy.html&lt;/a&gt;&lt;p&gt;* Protocols and constructions should be designed to minimize dependence on randomness, the way DJB&amp;#x27;s EdDSA does: &lt;a href=&quot;http://ed25519.cr.yp.to/ed25519-20110926.pdf&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;ed25519.cr.yp.to&amp;#x2F;ed25519-20110926.pdf&lt;/a&gt;&lt;p&gt;* Crypto performance is both not taken seriously as a research goal and an excuse for the deployment of terrible cryptography. This isn&amp;#x27;t so much a hobby horse of DJB&amp;#x27;s as it is &lt;i&gt;his entire research career&lt;/i&gt;: &lt;a href=&quot;http://cr.yp.to/cv/research-net-20070115.pdf&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;cr.yp.to&amp;#x2F;cv&amp;#x2F;research-net-20070115.pdf&lt;/a&gt;&lt;p&gt;* DNSSEC, with its core design goals of &amp;quot;sign-only&amp;quot;, &amp;quot;sign offline&amp;quot;, and &amp;quot;sign from the root down&amp;quot; is a terrible idea. A sane design would look more like DNSCurve: &lt;a href=&quot;http://dnscurve.org/&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;dnscurve.org&amp;#x2F;&lt;/a&gt; (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).&lt;p&gt;Unsurprisingly, considering the source, these are all really great important ideas. Bernstein is one of my heroes, and I&amp;#x27;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&amp;#x27;s research over the last 15 years.&lt;p&gt;I&amp;#x27;m surprised he didn&amp;#x27;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.</text></item></parent_chain><comment><author>jvehent</author><text>I found this particular talk to be different that the usual DJB. It felt more like a self-reflection on why, despite being technically correct, his cryptographic solutions always fail to gain mainstream traction.&lt;p&gt;I have a lot of respect for DJB and for the way he always challenges the status-quo. This talk is an excellent summary of the current issues in the crypto industry. But he ignores the fact that we use AES, SHA and RC4 because _it&amp;#x27;s easy to use them_. And his solutions are never easy to use.&lt;p&gt;Make Nacl dead simple to use. Write clients and servers that use it. Integrate it into Firefox, Chrome, Dovecot, Nginx, Postfix, cUrl, etc... and people will slowly move away from TLS and its broken crypto.</text></comment>