Why don't we use Blowfish if it hasn't been cracked?

Question

Since Blowfish is old, well-audited, and has no published attacks, why are we using AES instead? I know that Bruce Schneier said that Blowfish is insecure and told people to transition to Twofish, but why? AES has many vulnerabilities, such as padding oracle attacks and power-consumption analysis, but Blowfish doesn't have any well-known issues. And Blowfish can take a key up to 448 bits, which is larger than AES's 256 bits. Is there something I am not understanding? It's been under public scrutiny for the longest with the least issues.

Perhaps it is because of Blowfish's small block size?

Context: Is it safe to use Blowfish to encrypt strings of less than 30 characters?

Answer 1

Why don't we use Blowfish if it hasn't been cracked?

The reason is well-known, it has 64-bit block size and therefore it is vulnerable to birthday attacks. This is done for HTTPS and for more information see sweet32;

$$\text{Sweet32: Birthday attacks on 64-bit block ciphers in TLS and OpenVPN} $$

Is it safe to use Blowfish to encrypt strings of less than 30 characters? If I don't use it for HTTP, just for storing small strings, is it still insecure?

There is no problem. GnuPG made a recommendation for Blowfish; Blowfish should not be used to encrypt files larger than 4Gb in size. If you want to use a block-cipher from Bruce Schneier use the successor, the Twofish algorithm, as he said.

This recommendation 4GB makes $\approx 2^{33}$-bytes therefore, they recommended using at most $2^{30}$ blocks of encryption under the same key. With the birthday probability if you encrypt $2^{30}$ blocks you will have

$$(2^{30})^2/2^{64}/2 = 2^{60 - 64-1} = 1/2^{5}$$ probability of collision. This is still a high probability in the attacker's advantage.

---

What is Sweet32 in short:

The attack performed on the CBC mode of operation where the encryption is $$c_i = E_k(m_i \oplus c_{i-1})$$ wiht $c_{-1}$ is the nonce for the CBC.

Once one encrypts $2^{n/2}$ blocks with one key by the birthday attack we expect a collision on the ciphertext with 50% probability that can be observed by an eavesdropper. This means that $c_i = c_j$ with $i \neq j$ is observed. Since a block cipher is a fixed permutation under a key this implies that the inputs of $c_i$ and $c_j$ must be the same;

$$ m_i \oplus c_{i-1} = m_j \oplus c_{j-1}$$ with changing the side of the values we get $$m_i \oplus m_j = c_{1-1} \oplus c_{j-1}.$$ That is the eavesdropper knows the x-or of the two message blocks.

---

A short note padding oracles;

Padding oracle is first described by Serge Vaudenay in 2002;

• Security Flaws Induced by CBC Padding Applications to SSL, IPSEC, WTLS

years later real attacks are performed. Vaudenay applied it to RC5 in CBC mode, and it applies to any cipher that uses CBC mode as long as the server sends the padding-fail as an error. With the padding oracle attack, all messages can be revealed since it is a decryption oracle. Encrypt-than-Mac will prevent this attack.

---

Update for the comment;

It turns out that OP has X/Y problem; the short string is a password then the obvious choice is the well-known solutions like the Argon2 which is the password hashing competition, winner. It has two modes;

• Argon2d: is faster and uses data-depending memory access. Data dependency immediately enables side-channel. This is suitable for cryptocurrencies and applications with no threats from side-channel attacks.
• Argon2i: uses data-independent memory access and this is preferred for password hashing and password-based key derivations.
• If you are not sure about which one to use then you can use the combined mode Argon2id.

Answer 2

The biggest problem is the 64-bit block size already mentioned in kelalaka's answer, but Blowfish has a couple of other issues:

• It can't be implemented using the hardware AES acceleration found in many modern CPUs. While this is obviously unfair, it's a reality of the world right now and it's a factor in many people's choice of AES. The hardware instructions not only provide much higher throughput but also protect against side-channel attacks.

• It uses 4 KiB of S-boxes which depend on the key and are accessed in a data-dependent way on every round. I don't see how this could be protected against cache-timing attacks except by loading the tables in their entirety on every round, which would have terrible performance.

Blowfish's flexible key length is arguably a disadvantage, since it's an invitation to use a passphrase or other non-random secret directly as a key. This is a bad idea: block cipher key setup is supposed to be as fast as possible, while passphrases should be run through a KDF that is as slow as possible. This is only a weakness if you don't know what you're doing, but if you do know what you're doing then there's never a reason to use a key longer than 256 bits.

Padding oracle attacks have nothing to do with the choice of block cipher; any Rijndael-based cryptosystem vulnerable to that kind of attack would still be vulnerable if you substituted Blowfish.