Can someone explain how SWEET32 is a viable attack?

[peter-h]

I've been trying to find out, and I get the basic idea (a cryptosystem with say a 64 bit key can generate only 2^64 different ciphertext blocks) but I can't see how this can be exploited because any competently managed website or server is going to block you long long before you reach even 0.1% into the download of the required amount of data.

Also the detection of a duplicate block seems to need the storage of all the blocks, or at least hashes of them which is not going to be any smaller.

[golden_labels]

First and foremost: it’s about block size, not about key size. Sweet32 itself presents the attack only for 128-bit and 168-bit ciphers (Blowfish, 3DES)

There is a bunch of unspoken assumptions in your post. But I can’t peek in your head, so I may only guess them and respond to my guesses.

The elephant in the room: the assumption about servers breaking connections. This is the easiest one to tackle, because it’s a formal logic error: a failure to properly negate a existential quantification. We can’t use an existential quantification to oppose another existential quantification. The presence of servers breaking connections is irrelevant here.

Further, there is an implication of incompetence for not breaking long-lived connections. That’s unfounded.

Such amounts of data are also routinely observed. To name a few common examples: wireless networks, VPNs, email transfers from/to large operators, continuous monitoring, backups and data dissemination, or database replication.

Then, Sweet32 is not proving vulnerability. The vulnerability was known before Bhargavan and Leurent’s publication. What Sweet32 authors did is showing that vulnerability is exploitable beyond the realm of spherical cows, and they are not even the first to do so. It’s more like the last nail to the coffin, not cutting a tree for one. Such displays are not meant to be reused directly in attacks. They are sounding devices, used to gauge how far the cryptographic ship is from crashing into ground. For a reasonable captain Sweet32 is enough to halt the ship and seek another route. Even if we could still pass this single shoal, we know this entire area is already a catastrophe awaiting.

Finally, the 785 GB mark is not a requirement. The number itself is is a result from this particular experimental setup and may be different in other scenarios. Other attempts are not even mentioning stream size, but deal with time or requests counts. There is a lot of slack coming from what the adversary may know about the plaintext.

But most importantly this is not a fixed value. It’s a probabilistic setup and the authors made a decision to choose number high enough to provide a reasonably high success rate. An actual adversary may accept much worse odds and reduce the amount of data needed.

If you’re interested in the background, among many publications in this very crowd is McGrew’s 2012 paper “Impossible plaintext cryptanalysis and probable-plaintext collision attacks of 64-bit block cipher modes”. Sweet32 references it too.

[Bud]

There is another angle to look at it, just like at any other vulnerability: if your company will get a security audit, the auditors do not care about viability of an attack. If a security vulnerability was identified and published, they will write a finding and will require you to address it, regardless of it is viable or not. So, unless you have academic interest in deep diving into it, from practical perspective better focus your efforts on remediation.

[ejeffrey]

At this point it's kind of irrelevant.

3DES and blowfish are functional obsolete.  Any security analysis is going to say they should be upgraded anyway.

I terms of viability as an attack: it results in a relatively small potential leakage of information.  Long lived sessions may be uncommon but they aren't unheard of.

In principle this could be easily mitigated by periodic rekeying but again: the ciphers in question are obsolete and have been for a long time.  Any system still using them is probably so old it has tons of other more serious flaws.  Unless you have a very specific situation where it is easy to mitigate this specific problem but can't change to a different cipher it's probably not something to worry about.

[5U4GB]

I've been trying to find out, and I get the basic idea (a cryptosystem with say a 64 bit key can generate only 2^64 different ciphertext blocks) but I can't see how this can be exploited because any competently managed website or server is going to block you long long before you reach even 0.1% into the download of the required amount of data.

It's not even that, it's an adaptive chosen plaintext attack which means you need to be encrypting data chosen for you by the attacker, under the same key the entire time, for 765GB worth.. to recover an HTTP cookie.  It's so ludicrously impractical that the only place it'd ever get any attention is at an academic conference that does crypto papers.

However it will then end up in a bunch of braindead "vulnerability scanners" run by auditors (perhaps KPMG) who charge five-figure sums run to said scanner and tell you that you need to fix your software.  One countermeasure some guys I know found for this was to identify when they were being scanned and feed back data that crashed the scanner, which meant they passed the audit since the auditors ran out of ideas once their software didn't work any more.

It really depends on what the point of the security audit/assessment is.  If you need to check a box that says "Passed a security audit" then you go to run-a-scanner auditors.  If you want to make sure your system is actually secure against attack you engage a pen-testing company.  Unless you're really exceptional they will find vulnerabilities that need fixing, and none of them will be related to crypto.