# Tag Info

12

Blowfish has strong points regarding speed because bulk encryption (and decryption) reduce to an alternation of: a 8->32-bit table lookup, and one or two 32-bit operations (addition or XOR). That structure is very well suited to 32-bit CPUs with a short pipeline and a fast cache of at least 4 kByte; and is well suited for a straight C implementation, which ...

7

bcrypt uses Blowfish, which is a block cipher (albeit with a much enlarged key schedule). As such, Blowfish implements a permutation of the space of 64-bit blocks; and there should be no way to distinguish Blowfish (using a random key) from a permutation extracted at random, with uniform probability, from the set of permutations over 64-bit blocks (there are ...

5

Using EAX with a 64-bit block cipher is problematic, because the short block size causes some weaknesses due to internal collisions. I do not recommend it. Use a 128-bit block cipher. Indeed, the world has moved away from 3DES and towards AES exactly because of these fundamental problems with a 64-bit block size: the internal collision effect means that, ...

4

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 ...

4

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 ...

3

If you use CBC mode and your communication protocol looks like SSL, then you may have trouble. In SSL 3.0 and TLS 1.0, the IV for each record is the last block from the previous IV; this implies that an attacker who can both inject some data of his own in the stream, and observe the outcome, may know the IV for the next record and choose his data ...

3

If there was a full 64-bit block of known plaintext, there would be a very fast attack using precomputation. You can build a precomputed table of all $2^{40}$ ciphertexts. Once you've got the precomputed table, recovering a key (given a ciphertext) would require just a single lookup in the table, so recovering a key would be extremely fast. Storing that ...

3

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 ...

2

It is not really clear what you propose instead of the original algorithm - using ExpandKey(state, salt, key) instead of ExpandKey(state, 0, key)? What about the second call ExpandKey(state, 0, salt)?. You are right, each ExpandKey(state, 0, xxx) contains one XOR-ing of xxx into the P-array, and then Blowfish-encrypting multiple 64-bit blocks of zeros – in ...

2

Blowfish has a 64-bit block size whereas AES has a 128-bit block size, so you are sort of comparing apples and oranges (there are some things you can do in AES which would be unwise in Blowfish, in particular Blowfish in CTR mode can be distinguished from a random stream after only a few dozen gigabytes of output - see fgrieu's answer here, replacing 128 by ...

2

There seem to be some errors or inconsistencies in the question. If $P \oplus P' = [0000\delta 000]$, and we use the 2-round structure shown in the picture, then the corresponding ciphertext pairs should satisfy $C \oplus C' = [xyzt\delta000]$. This is different from what you wrote (did you omit the final swap shown in the picture above?). If we let ...

1

Because I didn't get any answer, I did some experments with Blowfish's F function and here are my observations: Because Blowfish's F function is not bijective, on average only every second value is returned and therefore different input can output same value (F(x) = F(y)). By reducing number of S-boxes this non-bijectivity becomes even worse. About 8 to 32 ...

1

Regarding your brute-force Blowfish attack: I believe I may be familiar with the protection scheme you describe. It turns out that it may be even more broken that you'd expect from the description, in that a) the actual keyspace may be rather more limited than 40 bits and b) the author may not have been terribly aware of the consequences of using the ...

1

A problem with your proposed solution is that the digest of the password is now "password equivalent". So, what does hashing it before sending it gain you? That said, I don't think either of your concerns are concerning (or should be concerning). For the first, see this. If anything, most passwords will have less than 256 bits of entropy anyways. For ...

1

Yes. Blowfish's S-boxes serve a similar purpose as AES's S-box. The P-array is used as part of the key schedule, to make sure that each round is different (this helps prevents slide attacks and related-key attacks). I recommend you read the official specification of Blowfish and Wikipedia's article on Blowfish for more about the design rationale for ...

1

Something similar as what you suggest is already known as "Expensive key schedule Blowfish", or "EksBlowfish". It is the encryption algorithm in the core of Bcrypt (a slow hash function designed for password hashing). It also incorporates a salt, and its setup function is like this (retyped from the paper): EksBlowfishSetup(cost, salt, key): state ← ...

Only top voted, non community-wiki answers of a minimum length are eligible