Sweet32 Nearly a Year On: Vulnerabilities People Stop Caring About

Maybe I’m a little strange when it comes to security – for content that I care little about, I’m very lax.  My web history? Anyone can see it.  Passwords to my social media?  Eh, I don’t represent anything official, I’ll use the same one for all of them (and don’t pretend you don’t too).  But when I get to a point where security matters for me even a small bit – my credit card info, my bank account login, or my professional passwords, I get to paranoia levels of cautiousness.  You better have the most up to date SSL ciphers and every page better be HTTPS or I’m going to back out.  When working with my job’s administration to set up credentials I even get wary telling it over the phone, wondering if there might be a man-in-the-middle listening in (hint: there shouldn’t be, security is set up properly on it).

So one of the most frustrating things to me is to see how laissez-faire security blogs have treated Sweet32, a vulnerability released to the public back in August 2016.

The Birthday Paradox

On a basic level, Sweet32 and attacks like it are very simple.  They’re based off of the same concept as the Birthday Problem – the mathematical “paradox” where in a group of only 23 people there’s a 50% chance two of them share a birthday, even though there are 365 days in a year.

The vulnerability utilizes this concept to make it trivially easy for a computer to find a collision – two values which return the same hashes – which can then be used to support a man-in-the-middle attack, hijack a browser session, or other attacks that need a matching hash to function.  Many much more detailed breakdowns of the paradox and its use in the vulnerability are out there, but the essential takeaway is you need to make the number of “days in a year” too high for there to be a reasonable chance of a collision.  This means increasing the size of the blocks – the chunks data is broken into and then encrypted.  Triple-DES (a cipher that, for anyone who has taken any security class, is well known as being wholly unusable at this point) uses a blocksize of 64 bits.  AES, a much more secure encryption method which anyone who’s dealt with SSL certificates likely recognizes, uses 128 bit blocks, which increase the requirement from a trivial amount of data to examine in DES to a currently nigh impossible amount of data to brute force for the forseeable future.

Upgrading is Hard

So why not just upgrade everything to AES?  It’s widely and easily available at this point in the game.  Well… yes, in an ideal world that’s what would happen. But upgrading is hard.   Sysadmins probably recognize this even if it’s unrelated to security –  even if you had all the money in the world, completely modernizing your hodgepodge of infrastructure will take a huge amount of time and effort.  We’re in the same spot here – so many things were built with triple-DES as the go-to encryption method, even phone networks.  And even for those who have no issue upgrading currently, we still have the problem of legacy ciphers – supporting these old, out of date encryption methods so that all kinds of users can access your content.  It’s an unavoidable part of the current state of affairs of the internet, but it causes these significant problems.

This information can be found widely over the internet.  So why bring it up?  Well, as I mentioned at the start, to show my frustration with the hesitation to move away from supporting legacy ciphers and upgrade any out of date encryption methods currently being used.  At least enough to avoid something as low-level as a veritable brute force attack like Sweet32.  Other security bloggers do have a point when they explain why they feel nobody should panic about this even though it’s still a widespread vulnerability – there haven’t been any reports of it actually impacting anyone.  Alone finding a collision does nothing.  It supports a MitM attack but you need other security failures to actually have a successful attack. Devoting resources to fixing something that currently hasn’t verifiably impacted anyone is a hard sell.

But people who work in security, even sysadmins who just need to secure their systems on the side, know that any security is a hard sell.  It like insurance – hard to justify until you realize that it prevented something catastrophic.  It’s for this reason I think even simple vulnerabilities like Sweet32 should be taken seriously.  Upgrade, end support, require new access methods.  Just fix it before it ends up being part of an actual disaster that hits the front page of BBC explaining why worldwide banks were shut down for the day.


Are your systems vulnerable to birthday attacks?  Are you planning on fixing them, or do you agree that our always limited resources are better spent elsewhere, security-wise or not?  Can you not actually fix the issue in your systems for legacy support reasons?  Let me know!

Leave a Reply

Your email address will not be published. Required fields are marked *