# Tag Info

21

TL;DR: Twofish and Threefish are fine. It is not the best idea to have the cipher you want to use hardcoded because you can't upgrade easily when one of them is broken. to quote mikeazo in the comments: What you should do is develop your application to not be bound to a specific cipher. Twofish In 1999, Niels Ferguson published an impossible differential ...

18

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

11

If you want to choose a fishy cipher by Bruce et al, I'd go for Twofish. Reason: Blowfish is not recommended anymore because of the small block size of 64 bits, among others. Even Bruce is not recommending it anymore - it's an old but unbroken cipher; Twofish is a relatively modern 128 bit block cipher which is a drop in for AES - for the simple reason ...

9

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

8

Your best bet is, I think, to do it the other way round. encrypt securely using a proven algorithm. make the encrypted text human readable. For example: AES-256 encode "Squeamish Ossifrage" using some key. Get, say, 512 bits of absolute gibberish. That is 64 bytes of 8 bits each; each byte can have one of 256 values. Get a dictionary of 256 words (...

7

The encryption is EDE with Blowfish CBC. To decode the cryptotext ct reverse the encrytion, ie do CBC_Decrypt(key3, iv3, ct, t3) CBC_Encrypt(key2, iv2, t3, t2) CBC_Decrypt(key1, iv1, t2, pt) After this the plaintext pt will start with: El truco estaba en desencriptar utilizando el metodo 3DES pero con distintos algoritmos de encripcion. Aunque usualmente ...

7

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

6

An important property of a ciphertext is that it has to be indistinguishable from truly random data. This allows the encryption cipher to produce ciphertext that reveals no information about the plaintext (other than size) or the encryption key. In fact, this property even allows encryption algorithms to act as pseudorandom byte generators by simply making ...

5

I didn't find anything about the exact way Crashplan encrypts files, only that it uses Blowfish in CBC mode. The block size of Blowfish is 64 bit, so there are $2^{64}$ different input blocks and the same number of output blocks. All in all $147573953$ terabytes of different output data. The problem with this is the birthday attack. Summarized it says that ...

5

Bruce Schneier's Description of a new variable-length key, 64-bit block cipher (Blowfish) (in proceedings of the first FSE conference, held Dec. 1993) defines that Blowfish's key is of 4 to 56 bytes (32 to 448-bit), with this rationale for the maximum: The 448 limit on the key size ensures that the every bit of every subkey depends on every bit of the key....

5

The quoted passage of the Wikipedia article is wrong does not at first reading seem to match Blowfish as in Bruce Schneier's Description of a new variable-length key, 64-bit block cipher (Blowfish) (in proceedings of the first FSE conference, held Dec. 1993) which for this same operation reads: XOR P1 with the first 32 bits of the key, XOR P2 with the ...

4

Of those you listed, AES is the best to study. Not only is it the standard that is used everywhere, it has a huge literature of people explaining it and analyzing it, far larger than any of the others on your list. Also, compared to the others on your list it is easier to understand why AES strongly resists certain major classes of attack (like linear and ...

4

First, it is important to learn the basics behind all symmetric ciphers. You can get this from Handbook of Applied Cryptography, see Chapter 7, especially 7.1, 7.2, 7.3. If you understand those three sections, you will be off on the right foot. From there, I would suggest just diving right into AES. It isn't that terribly difficult (yes, there are easier ...

4

The same way other ciphers, basically, only it does it better than some. From the Blowfish paper these were the relevant building blocks "demonstrated to produce strong ciphers" in previous designs: "Large S-boxes. Larger S-boxes are more resistant to differential cryptanalysis." "Key-dependent S-boxes. While fixed S-boxes must be designed to be resistant ...

4

One method of doing this would be to construct a Feistel network using the n-bit blockcipher as a round function. A drawback of this approach is that because you're using a blockcipher (a pseudo-random permutation) in place of a pseudo-random function, you are almost immediately limited to being secure to only $q \ll 2^{n/2}$ queries as a result of the ...

4

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

4

No, you cannot, unless you have repeated messages, or use different keys. A block cipher such as Blowfish is a keyed random permutation or bijective mapping. That means for each key any plaintext block is mapped to exactly one ciphertext block during encryption, and the ciphertext block is mapped to that particular plaintext block during decryption. For ...

4

That looks like a rather stupid proprietary padding method which uses 16 bit little endian encoding - as usual for x86 based CPU's. It seems to fill the rest with random padding, possibly to try and avoid leaking information using padding Oracle attacks. It is a good idea to check that the size is not bigger than 8, otherwise a bad ciphertext could remove ...

3

This is just a polygraphic substitution cipher, where you have a fixed substitution over the set of words in the English language. As your input text has a non-uniform distribution, this will show in the ciphertext. As you stated, you want to add fake words to make frequency analysis more difficult, however, it's not that simple: Just adding fake words ...

3

First of all, I'd like to point out, that, because you are using no chaining algorithm, this cannot be secure encryption. (if you re-use the key for a long time, then someone with good math skills would be able to decrypt the messages) Secondly, since the resulting words need to be real English language words, you have to have a dictionary available as part ...

3

You are correct in that after the birthday bound you will leak some plaintext in random 8-byte blocks. Nova's answer has the specifics and links to useful sources. To give you a rough idea of the risk, you can look at what percentage of the data could leak. 10 TB is about $2^{40}$ blocks. The expected number of collisions is $2^k (1-(1-2^{-n})^{2^k-1})$, ...

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

No, not unless the input for the key small enough to be brute forced or guessed. For any secure block cipher the key cannot be retrieved even if you have the input (block of plaintext) and output (block of ciphertext). And there are no known attacks on Blowfish that break the cipher significantly. So it really doesn't matter how the block cipher is used. ...

3

Is there a way to produce a decrypted output with the same size as the input message? Yes, CTR mode should work for that. You must have a broken implementation as there is no padding required for CTR mode. You could simply use the leftmost bytes of the ciphertext though. If decryption fails because of that then you could simply pad the ciphertext with zero'...

3

First, remember that any cipher must be functionally correct, that is for any valid plaintext $$\operatorname{Dec}_k(\operatorname{Enc}_k(m))=m$$ This effectively means you must be able to properly decrypt any properly encrypted message. This also means that it cannot happen that $m_1\neq m_2$ with $\operatorname{Enc}_k(m_1)=\operatorname{Enc}_k(m_2)$ can ...

3

Ciphertext stealing doesn't bring you any security benefits, although – if you're hell-bound on using CBC mode – it could avoid padding oracle attacks. Otherwise it is just a way to avoid padding the plaintext and therefore increasing the ciphertext size in CBC mode. Ciphertext stealing is independent of the block cipher used. So you could use it with 3DES, ...

3

It looks like the library is treating the string as the key to Blowfish, which has a veriable key size; the way the keysetup is done (with a cyclical use of the key bytes, see more details on the Wikipedia page) implies that key $k$ of length $n$ and key $k||k$ of length $2n$ have the same expanded key and thus an equivalent encryption/decryption function. ...

2

No, the most you can do is to compare ciphertext blocks for equality and link those blocks with identical plaintext. That ECB is used does not hurt the security of Blowfish by itself. Block ciphers should not be vulnerable to known plaintext attacks, and there seems to be no known attack on Blowfish in this regard. To state it a bit more formally: that ECB ...

2

The -bf-ecb cipher is expanding the key to 128 bits by zero extending it. The output from -p is the telltale here: \$ openssl enc -bf-ecb -e -in plaintext.txt -out ciphertext.txt -nosalt -K FFFFFFFFFFFFFFFF -p key=FFFFFFFFFFFFFFFF0000000000000000 Blowfish is defined for 32-448 bit keys, and it appears the OpenSSL implementation chose 128 bits as the size ...

2

CMAC (or OMAC1) is the underlying MAC algorithm that provides authentication and integrity for EAX. Is stated in NIST SP 800-38B: Because CMAC is based on an approved symmetric key block cipher, such as the Advanced Encryption Standard (AES) algorithm that is specified in Federal Information Processing Standard (FIPS) Pub. 197 [3], CMAC can be ...

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