1

Backgound

There is a lot of hype about the Sweet 32 paper in the recent days. The paper shows that 64bit block size symmetric cyphers are too vulnerable today, it performs a birthday attack on blowfish2 in two days.

The point of the paper is that only 785GBs of traffic are used (over HTTP, only 32GB of cyphertext traffic is needed, the rest is HTTP bloat). That amount data is not much with today's transfer speeds and data usage.

It also argues that OpenVPN uses blowfish by default, and also Triple-DES (another 64bit block size cypher) is used as a legacy fallback in some browsers.

VPN and browsers certainly carry a lot of data, and a lot of personal data within that, and are certainly vulnerable to the attack. Moreover, we can definitely consider that, since users use VPNs and browsers without knowing much about encryption, the applications are actively (not sure if i'm using the correct word) vulnerable.

That's all well defined but what about other, less popular and different (in terms of how they work) applications. See the question:

Question

Vim (arguably one of the most popular editors around) uses blowfish2 as the main algorithm to read and write encrypted files. It practically uses only blowfish2 (it can use blowfish or pkzip but those are are just plain bad).

With Vim you do not send several gigabytes of files over an unprotected network, moreover, with Vim it would be rare that you would use the same key for several files. Although someone that is on the same machine as you are may have access to several gigabytes of your encrypted files (but then it is more a question of permissions, I believe).

The issue has been booming on the Vim github and mailing list. Yet, it put me in doubt about the main difference between a browser and an application like Vim: a browser will use encryption behind the scenes without telling the user, in Vim the encryption must be configured actively by the user.

An user aware of problems with blowfish2 can simply use vim-gnupg to encrypt his files. Therefore it is hard for me to believe that the sweet32 publication makes Vim actively vulnerable. It would be great to fix it in Vim alright, but arguing that it is a huge issue is not really true.

In general, the question in all this context is:

  • Can an application that allows users to configure it to use a vulnerable encryption method be considered actively vulnerable? (given that there are alternatives)
2

You need to take into account that there is a difference between disk/file encryption and network encryption. The paper talks primarily about streams of information thus networks. As you mentioned briefly, much of the transmitted data actually is HTTP related stuff, and that is an important part of the attack.

The 64bit ciphers are not actually broken (ignore crypto definition for the moment), but more weakened to a point they become vulnerable, and so leave a good to far chance they could be converted back to plaintext with modern hardware (or at least some pieces).

In order to do this, you need lots of information to detect specific patterns. Those patterns will only emerge in large volumes of repeated data, and luckily this is often the case with networks. HTTP is a great example, although keeping a connection alive long enough to capture all the data, without missing packets or encounter malformed frames is rather difficult over the internet. In a lab the circumstances are ideal, which makes this exploit work.

To answer your question, applications such as Vim use blowfish for file encryption, which stores data only once (or multiple times, but not repeatedly). This limits the chance of being broken significantly. Don't think file encryption that uses 64bit block ciphers is problem-free, which is why the advise is to omit 64bit ciphers all togehter. For OpenVPN, this does not leave much cipher suites to pick from, but change is coming..

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.