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?

  • 12
    $\begingroup$ Padding oracle attacks aren't specific to AES, and power-analysis attacks will likely work on most Blowfish implementations as well. $\endgroup$ – forest Jan 2 at 1:46
  • 1
    $\begingroup$ I've roll-back the edit. The question already had two answers and become an HNQ. What you edit is diverging the main course of the question. If you have a different question then you are free to ask another. $\endgroup$ – kelalaka Jan 2 at 17:47
  • $\begingroup$ Ok, thanks. I didn't know about keeping questions on topic, although I probably should have :P $\endgroup$ – HACKERALERT Jan 2 at 17:54
  • $\begingroup$ Once answered it is not a good action to diverge the question, as long as you may ask the answer(s) about that. $\endgroup$ – kelalaka Jan 2 at 18:02

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 HHTPS 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;

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 padding oracle attack all messages can be revealed. 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.
  • $\begingroup$ Ok, that seems reasonable. If I don't use it for HTTP, just for storing small strings, is it still insecure? $\endgroup$ – HACKERALERT Jan 1 at 18:27
  • 1
    $\begingroup$ Makes sense now, thanks for your answer! $\endgroup$ – HACKERALERT Jan 1 at 18:34

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.

  • $\begingroup$ Thanks for your reply. I intend on using 10000 rounds of SHA3_512, 16384 rounds of PBKDF2 and then Scrypt with N=16384, r=16, p=4. I think that should be enough. $\endgroup$ – HACKERALERT Jan 2 at 3:04
  • 10
    $\begingroup$ @HACKERALERT No. Use Argon2. Don't use some custom amalgamation of KDFs. $\endgroup$ – forest Jan 2 at 3:55
  • $\begingroup$ Oh, good idea, I thought about that but didn't know which one would be best. Argon2 or argon2i or argon2id? I would prefer security over speed. Thanks! $\endgroup$ – HACKERALERT Jan 2 at 15:54
  • 1
    $\begingroup$ Actually, I've solved my question from this answer: crypto.stackexchange.com/questions/72416/…. I'll probably use argon2d for max security, since the encryption will be done in a browser and side channels don't matter. Also, it's not a communication protocol, so there's no Blowfish risk. It's similar to a password manager in terms of how it functions. $\endgroup$ – HACKERALERT Jan 2 at 16:29
  • 3
    $\begingroup$ @HACKERALERT Scrap them all in favor of Argon2. And I would recommend Argon2id, which is a hybrid of the two and is generally recommended for most applications. $\endgroup$ – forest Jan 3 at 1:41

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.