Why a Longer Blowfish Key Cannot Fix a 64-Bit Block

A VPN profile offers Blowfish with a 448-bit key, and someone proposes using the longest key as a way to keep the cipher. The key length is real, but it is the wrong number to optimize. Blowfish transforms 64-bit blocks no matter how long the key is, and the block width is what limits how much traffic one key can safely protect. Run the checks below in order and stop at the first one that clears the service, because a later step cannot repair an earlier one.

Check what the peers actually negotiate

Read the data-channel cipher from both ends, not from the profile you intended to deploy. A client configuration can list several ciphers, and the selected one is the result of negotiation between two implementations and their versions. Raise the log verbosity on a test connection and read the data-channel line, which names the cipher and the key size actually initialized.

If the negotiated cipher is AES-GCM or ChaCha20-Poly1305, stop here. Those constructions use a 128-bit block and authenticate the payload, so the 64-bit collision argument below does not apply to them.

Separate key length from block width

Blowfish accepts keys from 32 to 448 bits, and the algorithm author documents both numbers separately. The key is the secret; the block is the unit of transformation. Making the secret longer makes guessing it harder, and it does nothing to the width of the block the cipher processes.

In CBC mode the cipher is applied to fixed-width blocks, chained with the previous ciphertext block and padded at the end. For Blowfish that width is 64 bits, or eight bytes. The key schedule can be as large as you like; the chain still advances eight bytes at a time.

That is why raising the key length is not a mitigation. It addresses brute force against the key, while the collision risk below is a property of the block width and the mode.

Run the birthday arithmetic on the block size

A 64-bit block has a birthday scale of roughly 2^32 blocks encrypted under one key before collisions become likely. Each block carries eight bytes, so the same scale is about 2^35 bytes, or 32 GiB of data under a single key.

Treat that as a scale, not a quota. Collisions are probabilistic, and whether one leaks anything depends on the mode, the traffic pattern, and whether the attacker can recognize or influence the surrounding plaintext. The first byte past 32 GiB is not a decryption event, and the first 32 GiB are not certified safe.

The Sweet32 researchers demonstrated practical attacks against 64-bit block ciphers in 2016, including an OpenVPN scenario, under conditions that required observation and traffic generation. Their published defaults and software versions are historical context, not a description of your deployment.

Decide whether CBC reuse matters here

In CBC, a repeated ciphertext block means the two plaintext blocks differ by a known relationship, because the chaining XOR cancels. An attacker who can observe the ciphertext and knows or can influence one of the plaintexts may recover information about the other. The Blowfish key is never needed for that.

So the relevant questions are how long a key stays in service, how much traffic passes under it, and whether anyone can watch and steer that traffic. Rekeying lowers the block count per key, but a time interval is not a byte limit: a busy tunnel can move far more data than an idle one in the same hour. If you keep a legacy cipher, derive the limit from the construction and the actual volume, not from a round number.

If the measured volume per key stays far below the birthday scale, the exposure is smaller. It is still not zero, and it is still a reason to plan a migration rather than to stop worrying.

Replace the cipher instead of the key

Move the service to a supported AEAD cipher, and confirm that both peers, their versions, and their cryptographic backends can negotiate it. Raising the Blowfish key length changes nothing that matters, and guessing a new directive on one client is how a working tunnel becomes a broken one. Test the change on one client and one server before you touch the rest of the fleet. Keep the old profile available for rollback until the new cipher has passed a full connection cycle.

Keep certificate verification and account authentication in place during the change. They answer different questions: a successful login cannot widen a block, and a better data cipher does not excuse trusting the wrong server.

Close the check by reading the negotiated cipher again on a fresh connection, then confirm the old cipher is no longer accepted. If a peer still offers it, the migration is not finished, whatever the profile on the other side says.