Big data busts crypto: 'Sweet32' captures collisions in old ciphers Researchers with France's INRIA are warning that 64-bit ciphers – which endure in TLS configurations and OpenVPN – need to go for the walk behind the shed. The research institute's Karthikeyan Bhargavan and Gaëtan Leurent have demonstrated that a man-in-the-middle on a long-lived encrypted session can gather enough data for a …
"2,000 requests per second in a single TLS connection. In our experiment, we were lucky to detect the first collision after only 25 minutes (220.1 requests)"
2,000 requests per second is 120,000 per minute, meaning 3 million in 25 minutes.
Could someone explain what 220.1 requests is supposed to be ?
Because if they managed to get their collision in only 220 requests, or even 220 100 requests, then this thing is more dangerous than they say.
Yep, there's a transcription error from the original article and 2^20.1 got changed to "200.1" and 2^36.6 got changed to "236.6".
You are correct that 2^20.1 (1123835) would still be too low at 2000 requests per second for 25 minutes (3000000) but the original article did say "up to" 200 requests per second. I don't see anything to note whether 2000 requests per second could be sustained.
It would seem to be something that might have been better clarified in the original article and definitely better transcribed by The Reg.
So, they get the login cookie for the malicious site that they control, after it's had lots of cyber chat with another site that they control. This is about the connection and login to their malicious site. I don't understand how that helps them to break the encryption of the user's VPN link, because I always assumed that the VPN was 'transparent' and its encryption was between the user and the end point operator (who must be trusted).
It's not inconceivable, however, that there are a lot of places with VPN installed a long time ago that haven't ever been reconfigured ("because it works") or upgraded.
But then, the problem is that, rather than anything to do with a weakness in the ciphers used.
One of our customers last week, complaining about an error they were getting in their logs
"well the old VPNs worked so why don't we go back to using DES?".
(Old VPNS used 3DES, new VPNS are using AES and connecting just fine from our end, the error seems to be an IP routing error rather than encryption algorithm problem. Oh, and it's re-keying every hour)
Anon to protect the guilty.
The half-terabyte of raw data looks like a very unlikely pre-requisite. The average punter would have to max out their allowance for several months to exchange that much. Is the attack still feasible for (say) 100 times less raw data, which would seem to me to be a more reasonable amount to pull over in a single session. (Even that, of course, is 100 times more data than might appear in a truly interesting SSL session, such as a visit to a bank.)
Or am I thinking of the wrong target here?
Not just the monumental patience required, 2000 requests per second (even split across 'a few dozen') on top of everything else would definitely get noticed, even the crappiest ad scripts don't dare to dream of burning that much CPU/bandwidth. On the other hand this may well turn out to be their true purpose, with banners just being a handy sideline.
Also, if your HTTP connection is open for long enough for 785GB then security isn't your problem, it's chafing, blisters and RSI...
If you design a client for an encrypted connection that doesn't re-key for 750 GB, you should have your birth certificate revoked...
At 785 GB and a 64-bit key, that would be a payload-to-key use factor of 13,170,114,560. Any reasonable security engineer would expect their encryption to be broken at a hundredth of that...
People wanting remote access to "stuff."
And the people most likely to be running short code length connections?
Large businesses who got it running a long time ago and don't want to fix what's not broken.
Yes, I think quite a lot of people should be worrying.
HTTPS shouldn't be an issue to fix, but OpenVPN gets the encryption mode defined at both ends, and both must match. Unlike HTTPS, you can't define several ciphers and just have the other end pick one.
However, in the settings there's this:
--reneg-pkts n
Renegotiate data channel key after n packets sent and received (disabled by default).
--reneg-sec n
Renegotiate data channel key after n seconds (default=3600).
When using dual-factor authentication, note that this default value may cause the end user to be challenged to reauthorize once per hour.
Also, keep in mind that this option can be used on both the client and server, and whichever uses the lower value will be the one to trigger the renegotiation. A common mistake is to set --reneg-sec to a higher value on either the client or server, while the other side of the connection is still using the default value of 3600 seconds, meaning that the renegotiation will still occur once per 3600 seconds.
The solution is to increase --reneg-sec on both the client and server, or set it to 0 on one side of the connection (to disable), and to your chosen value on the other side.
I would advise that if people are unable to migrate from Blowfish in their OpenVPN configurations, they make use of these two settings to at least ensure the keys are re-negotiated in time. The default of 1 hour sounds safe unless you have very busy VPN links. --reneg-pkts would make doubly sure that the keys are negotiated often enough to make this attack nearly impossible unless the attackers were very lucky indeed.
New installations should probably look at other ciphers, I tend to stick to the AES ciphers. (See openvpn --show-ciphers for a list)
To break a code one needs enough data to give clues to the key. This has always been true. The only difference between now and the Enigma machines is the amount of data needed.
Encryption will never be perfect and will be broken with enough time and effort. It just has to be good enough so the plain text is useless one obtained.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
