To put this in context: You should have been avoiding 64-bit block ciphers to begin with.<p><a href="https://gist.github.com/tqbf/be58d2d39690c3b366ad" rel="nofollow">https://gist.github.com/tqbf/be58d2d39690c3b366ad</a><p>Furthermore, as the article says from the getgo, birthday attacks are not <i>new</i>. They are a known problem.<p>What's new is someone wrote a paper describing a practical attack, and actually bothered to generate enough traffic to exploit the birthday bound of a 64-bit block cipher.<p>Your takeaway from this should be:<p><pre><code> - If it's not AES or CHACHA20, disable it.
- If it's not AES_GCM or CHACHA20_POLY1305, consider disabling it.</code></pre>
From the article: "But the take-away is this: triple-DES should now be considered as “bad” as RC4."<p>OpenSSL developer Mark Cox says: "tldr: "Low", Don't Panic!"
<a href="https://twitter.com/iamamoose/status/768431734547484672" rel="nofollow">https://twitter.com/iamamoose/status/768431734547484672</a><p>The researcher site is <a href="https://sweet32.info/" rel="nofollow">https://sweet32.info/</a><p>And RedHat has a nice writeup as well: <a href="https://access.redhat.com/articles/2548661" rel="nofollow">https://access.redhat.com/articles/2548661</a>
At what point does using TLS become malpractice? At what point does any software that links to OpenSSL become immediately suspect?<p>And TLS as deployed isn't secure <i>even when it works</i> whenever you don't trust the certificate authorities. Which is always.<p>Yes, I get that these are mega standards/libraries with a gazillion knobs, some of which are secure. But maybe kitchen sink crypto isn't the way to go? When will we say enough is enough and do something about it? For my part, I switched to using NaCl with public key pinning a few years ago and haven't looked back.<p>/sigh
Yet another example of key size not being the only thing to consider.<p>Also: OpenVPN's default cipher is blowfish? That would have been a great choice <i>20 years ago</i>, but not now. It shouldn't even be supported in 2016.
We changed the URL from <a href="https://www.openssl.org/blog/blog/2016/08/24/sweet32/" rel="nofollow">https://www.openssl.org/blog/blog/2016/08/24/sweet32/</a> to this post because it seems more explanatory.<p>There's also <a href="http://blog.cryptographyengineering.com/2016/08/attack-of-week-64-bit-ciphers-in-tls.html" rel="nofollow">http://blog.cryptographyengineering.com/2016/08/attack-of-we...</a>, via <a href="https://news.ycombinator.com/item?id=12353314" rel="nofollow">https://news.ycombinator.com/item?id=12353314</a>.