What Is the SWEET32 Attack and How to Fix It

In this article:

The SWEET32 attack is a cybersecurity vulnerability that exploits block cipher collisions. Attackers can use 64-bit block ciphers to compromise HTTPS connections. 

While block cipher algorithms like Triple-DES and Blowfish have been widely used as a mode of encryption for popular security protocols, the probability of SWEET32 vulnerability is rather low because it entails ensuring a number of other conditions to execute a successful attack. 

Below is a review of what the SWEET32 attack constitutes and how security issues related to it can be prevented. 

What Is the SWEET32 Attack?

The SWEET32 attack is based on a security weakness in the block ciphers used in cryptographic protocols. It’s similar to the RC4 attacks in terms of computational complexity. 

At the same time, block ciphers are used on many occasions. OpenVPN has as the default cipher Blowfish. Almost all HTTPS web servers support the Triple-DES algorithm. 

The SWEET32 attack visually represented in a graphic - Crashtest Security

How Does It Work?

Protocols like TLS, SSH, and OpenVPN often use block cipher algorithms for encrypting the data that travels between web servers and clients. The most common algorithms include Triple-DES, Blowfish, and AES. In them, the transferred data is chopped into chunks of a certain length — blocks — instead of encrypting the plaintext bit-by-bit. The blocks are then encrypted in a certain mode of operation. 

The block length of the cipher algorithm is different from the length of the key. The block size is set by the algorithm, so even if you opt-in for a large key size, it may still be limited by the cipher. 

In the Triple-DES and Blowfish algorithms, the block size is 64 bits, while for AES, they are 128 bits. The shorter a block size is, the more vulnerable it is to a birthday attack — a type of vulnerability based on the birthday problem in probability theory. This makes 128-bit ciphers like AES more secure.  

Short block sizes make web servers vulnerable to hitting the same hash for multiple inputs. By observing data exchange between a web server and a website for a longer period of time, remote attackers can recover secure HTTP cookies. 

In a nutshell, how secure a block cipher is based on the key size (k). When an exhaustive key search attack has a complexity of 2k, it can effectively reveal secure data. For CBC (3DES-CBC ciphers) and similar modes of encryption (CTR, GCM, OCB, and others), when block ciphers encrypt large data volumes, the block size (n) is also a security factor. Such block ciphers can encrypt only a fixed number of blocks — after 2n/2 blocks of data are encrypted with the same key — before causing a collision between two cipher blocks in the output, which means producing an identical ciphertext. This would lead to the same input, which in turn, can make it possible to obtain the plaintext blocks of the secure data. 

In the case of 64-bit block cipher algorithms, a collision attack can happen after about 32 GB of data. If an attacker generates a sufficient amount of data by using JavaScript that sends a high-speed stream from the browser to the web server, they can get access to HTTP session cookies. Still, experiments showed that as much as 785 GB of data may be needed for a practical collision attack. This made an attack scenario not so easy to execute. 

Discovery of the Vulnerability

Karthikeyan Bhargavanand Gaëtan Leurent, researchers at INRIA, the French national research institute for computer science, discovered the vulnerability in 2016. Their trials showed that recovery of an HTTP session cookie can happen in under two days using the long observation method. 

The categorizations include ​​CVE-2016-2183 for DES and Triple-DES ciphers and CVE-2016-6329 for Blowfish cipher vulnerability in CBC mode. 

Cryptographers had known about this potential vulnerability previously, but the extent and speed with which it can be exploited were revealed only by the INRIA researchers. 


The DES, Triple-DES, and Blowfish algorithms have been widely used in the encryption of block ciphers for major protocols like TLS, SSH, and OpenVPN. This means under the right conditions, a malicious user can obtain access to HTTP session cookies. The conditions include prolonged monitoring of traffic and executing JavaScript in the vulnerable browser that entails persuading a user to open an attacker-control website.

Since OpenVPN was using the Blowfish algorithm, this made the vast majority of VPN users vulnerable to the SWEET32 attack. 

The Triple-DES ciphers were quite popular with HTTPS web servers. However, for sessions with modern browsers, these servers would still have a cipher preference for stronger encryption. That’s why the INRIA researchers discovered that only 1-2% of HTTPS web servers rely on a weak cipher like Triple-DES. Of them, only 0.6% have the wrong configuration which puts them at risk of SWEET32 attacks. Most servers are configured to give preference to stronger cipher suites. This makes the Triple-DES vulnerability not that common.   

Still, some high-profile websites that accept a minimum of one million requests in the same connection — such as eBay, NASDAQ, Walmart, Amadeus, banking websites, and more — were at risk when the SWEET32 attack vulnerability was discovered. 

Post-Discovery Actions

When the SWEET32 vulnerability was discovered and publicly announced by security experts, major web browsers, OpenSSL, and OpenVPN all had to take measures to address the security risk. This put pressure on software vendors, as well as developers, to replace vulnerable versions and introduce strong ciphers. 

As a whole, there wasn’t any specific action recommended for regular users. OpenVPN users could change their settings to more regular rekeying through the reneg-bytes configuration directive.

SSL SWEET32 Security Assessment

Security Assessment Prevent SSL SWEET32


How to Prevent SSL SWEET32 Attack

To prevent SWEET32 attacks, you need to make sure your systems use only strong ciphers with large block sizes. A modern block cipher would rely on a higher number of blocks. 

You can refer to Secure TLS Configuration for more information on how to configure good cipher suites and minimize the chance of block cipher collisions.

Want to verify the level of security of your web app or API? You can use Crashtest Security’s SSL Vulnerability Scanner to discover vulnerabilities right away.