
Sweet32: Birthday attacks on 64-bit block ciphers in TLS and OpenVPN - pedro84
https://sweet32.info
======
CiPHPerCoder
To put this in context: You should have been avoiding 64-bit block ciphers to
begin with.

[https://gist.github.com/tqbf/be58d2d39690c3b366ad](https://gist.github.com/tqbf/be58d2d39690c3b366ad)

Furthermore, as the article says from the getgo, birthday attacks are not
_new_. They are a known problem.

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.

Your takeaway from this should be:

    
    
      - If it's not AES or CHACHA20, disable it.
      - If it's not AES_GCM or CHACHA20_POLY1305, consider disabling it.

~~~
espadrine
To me, the takeaway is that assumptions made for certain algorithms may lose
their validity within ten years. Exchanging 32GB over the Internet was absurd
in 1993, when Blowfish was published. With video becoming a bigger part of the
Web and Internet speeds going up, it may eventually stop being that way.

~~~
CiPHPerCoder
> To me, the takeaway is that assumptions made for certain algorithms may lose
> their validity within ten years.

If we hit 2^64 bytes transferred in under one hour as a norm before 2030, I'll
be immensely surprised. (This would implicate 128-bit block ciphers for
birthday collisions.)

~~~
emilburzo
> 2^64 bytes

18446.74 PB

~~~
tptacek
GCM has trouble after just 72PB, because of the way the initial block is
divided between counter and IV.

~~~
sdevlin
Where are you getting that number?

~~~
tptacek
The Noise framework documentation. I know there's "a" number for GCM, but I
always forget what it is, so I keep going back to Noise.

~~~
sdevlin
I don't think their bound is related to nonce-management issues. From the
documentation:

> The GCM security limit is 2^56 bytes because:

> This is 2^52 AES blocks (each block is 16 bytes). The limit is based on the
> risk of birthday collisions being used to rule out plaintext guesses. The
> probability an attacker could rule out a random guess on a 2^56 byte
> plaintext is less than 1 in 1 million (roughly (2^52 * 2^52) / 2^128).

~~~
tptacek
Yep. I'm wrong. I'll stop sourcing that number from Noise. :)

(Clarified offline: I'm thinking of the 32 bit counter in GCM, which will wrap
in tens of gigabytes worth of bytes under a single nonce. Not a TLS issue, a
concern for custom protocols.)

------
pedro84
From the article: "But the take-away is this: triple-DES should now be
considered as “bad” as RC4."

OpenSSL developer Mark Cox says: "tldr: "Low", Don't Panic!"
[https://twitter.com/iamamoose/status/768431734547484672](https://twitter.com/iamamoose/status/768431734547484672)

The researcher site is [https://sweet32.info/](https://sweet32.info/)

And RedHat has a nice writeup as well:
[https://access.redhat.com/articles/2548661](https://access.redhat.com/articles/2548661)

------
qwertyuiop924
Who's still using 3DES? That should already be a shooting offense anywhere
where security matters.

~~~
hsivonen
Sites that want to support IE8 on XP while disabling RC4.

[https://www.ssllabs.com/ssltest/viewClient.html?name=IE&vers...](https://www.ssllabs.com/ssltest/viewClient.html?name=IE&version=8&platform=XP&key=101)

~~~
qwertyuiop924
_sigh_

Thank you, IE, for once again royally screwing all of us over.

~~~
serge2k
Then drop support.

~~~
qwertyuiop924
I'm not the one writing for it, and I'm not the one who's forced to support it
by their employers.

~~~
tedunangst
Well then it seems a little exaggerated to say "all of us", no?

~~~
stcredzero
If you lump this in with all of the other effects IE has had on internet
standards over the years, then it is accurate enough.

------
rasz_pl
TLDR: ~800GB sniffed in one session to perform the attack. Only practical if
you never log off your torrent VPN.

------
erichocean
At what point does using TLS become malpractice? At what point does any
software that links to OpenSSL become immediately suspect?

And TLS as deployed isn't secure _even when it works_ whenever you don't trust
the certificate authorities. Which is always.

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.

/sigh

------
Panino
Yet another example of key size not being the only thing to consider.

Also: OpenVPN's default cipher is blowfish? That would have been a great
choice _20 years ago_ , but not now. It shouldn't even be supported in 2016.

------
yalogin
Why did Openssl only disable TDES and not Blowfish?

~~~
tptacek
Is there a browser that supports a Blowfish ciphersuite?

~~~
CiPHPerCoder
No, but it's the OpenVPN default, so unencrypted traffic over OpenVPN might be
interesting to play with.

------
dang
We changed the URL from
[https://www.openssl.org/blog/blog/2016/08/24/sweet32/](https://www.openssl.org/blog/blog/2016/08/24/sweet32/)
to this post because it seems more explanatory.

There's also [http://blog.cryptographyengineering.com/2016/08/attack-of-
we...](http://blog.cryptographyengineering.com/2016/08/attack-of-week-64-bit-
ciphers-in-tls.html), via
[https://news.ycombinator.com/item?id=12353314](https://news.ycombinator.com/item?id=12353314).

