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:
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
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)