# Is Blowfish strong enough for VPN encryption?

I'm looking at an OpenVPN connection between two sites configured to use 128 bit Blowfish in CBC mode, and trying to figure out how to assess the strength, but I just don't know enough of the maths.

I could ask this over on Sec.SE, but there I think the focus might be on whether it should use 3DES instead of Blowfish – here I guess I'm hoping for guidance as to relative strength of the algorithm, and whether a break is realistic when used this way.

-

Both 3DES and Blowfish are from the same pre-2000 era. They both offer adequate security, in the sense of "have been around for some time, no known weakness". Yet, they also both operate on 64-bit blocks. This implies some issues when you begin to encrypt more than about $2^{32}$ blocks of data -- that's 32 gigabytes, a somewhat large but not at all huge amount of data with today's networks. The issues are mostly theoretical (especially with CBC), but an awful lot can hide in a "mostly" (especially with CBC).

For the AES competition, NIST required that candidates use 128-bit blocks, for precisely that reason. Twofish is a 128-bit block cipher, designed by the same Bruce Schneier than Blowfish, and is claimed to be "related" to Blowfish, although the lineage is not totally obvious when you look at the algorithms.

There is a theoretical attack on 3DES which has cost about $2^{112}$ invocations of DES, along with a storage requirement of $2^{59}$ bytes (half a million terabytes)(if you go to a full million of terabytes, the storage can be hard disks and not RAM, which makes it slightly less unrealistic). That's totally undoable in practice, by a large amount, so no worry here.

3DES and Blowfish mostly differ administratively (3DES is a product of federal bureaucracy, so of course NIST approves of 3DES; whereas Blowfish is from a private individual) and on performance: on a PC, Blowfish is vastly faster than 3DES, whereas with dedicated hardware (FPGA, ASIC) the reverse is true. With a basic PC, the relative slowness of 3DES will not be a problem (or even be detectable) unless you run your VPN over fast links (you could get issues with 100 MBits/s links).

-
Being fair, DES was at least as much a product of IBM as of any federal bureaucracy (if anything, much more so). – Jerry Coffin Oct 31 '11 at 14:32

Thomas mentioned some "theoretical weaknesses" that can happen with $2^{32}$ blocks of data with CBC mode and an 8 byte block cipher; I will explore more about what that weakness is, and its practical relevance.

In CBC mode, we effectively send randomized data through the block cipher. However, there is a chance that it happens to encrypt the exact same data twice with the same key; this results in the exact same ciphertext block appearing in the encrypted output twice. If an attacker finds this, then he can deduce the exclusive or of the corresponding plaintext blocks.

How likely is this to happen? Well, after about $2^{32}$ blocks of data ($2^{35} = 34$ Gigabytes of data), the expected number of times for it to happen is about 1 (it might not happen at all, or it might happen 2 or 3 times); if you encrypt more data, it's expected to happen more often; if you encrypt less, it can still happen (but with a reduced probability of happening).

How much effort will an attacker have to go through to find those colliding pairs? Well, not very much; the biggest difficulty that the attacker would have is just dealing with the multigigabytes of data, and that's quite feasible for a determined attacker.

How much is this information leakage a security concern? Well, that depends entirely on the nature of the plaintext. The attacker will see the exclusive or of pairs of 8 byte segments, however he has no control over where they might appear. 8 bytes might be enough for him to guess the underlying plaintexts (and then, it might not), and even if he did, we might not care if he can deduce 16 bytes of data out of 34 Gigabytes. On the other hand, maybe we do care -- that's really up to the application.

Now, block ciphers with 16 byte blocks (such as AES and Twofish) don't have these concerns (this same weakness can be expected to take place after $2^{68}$ bytes of encrypted data; we will never need to encrypt that much data with a single key). This is one of the reasons we advise people to use more modern ciphers; this observation might not be a concern for a particular user, but with a modern cipher, we know it's not a concern for anyone.

-

Triple DES has 168 bit keys, but due to the meet-in-the-middle attack only provides 112 bits of security. Blowfish supports up to 448-bit security. As neither cipher has published practical weaknesses, you are best off looking at key sizes to help you judge strength. Given that, if strength of cipher is your only metric in deciding which cipher to use, it would seem that Blowfish is the better choice.

That said, there are probably other things to consider. For example, if this is on the server end, which cipher is more computationally intensive? That would affect how many simultaneous connections you can handle. Furthermore, if your server has a crypto accelerator, the algorithms that the accelerator supports would be important to look into. Other things to find out is what configurations the clients support, etc.

Edit: Not sure why I read twofish originally, updated to be more applicable to blowfish.

-
Mike - on that front, what is the difference between Blowfish and Twofish? The existing implementation uses Blowfish, which a quick perusal of Schneier's original docs seems to indicate as an outdated algorithm? – Rory Alsop Oct 31 '11 at 11:55
@RoryAlsop, I believe Bruce recommends using Twofish over Blowfish, although I believe there is no known practical attack on Blowfish. – mikeazo Oct 31 '11 at 12:49