Blowfish Questions

[azblue]

I have a few questions regarding Blowfish; I'm hoping someone here might know more about cryptography. (And I'm hoping I can adequately articulate my questions!)

Is Blowfish secure?

Regarding Blowfish, Wikipedia says, "no effective cryptanalysis of it has been found to date," which would seem to suggest it's unbroken; however, it also says, "Four rounds of Blowfish are susceptible to a second-order differential attack; for a class of weak keys, 14 rounds of Blowfish can be distinguished from a pseudorandom permutation."

Two questions arise from that.

1. Is Blowfish secure?

2. Is it SPECIFICALLY 4 rounds and 14 rounds that are issues? That is, are 3 rounds or 13 rounds or even just 1 round sufficient to avoid any weakness? Or is it "more is better"; should one aim for 15+ rounds?

What's the point of a block cipher?

For a given key, any given 64-bit plaintext will always be translated to a given 64-bit cipher-text. This would seem to give an attacker quite a bit of information -- frequently occurring information in plaintext will also be frequently occurring in ciphertext. Shouldn't good ciphertext be indishtinguishable from random data? Am I not properly understanding what a block cipher is for?
That brings me to my next question.

Can Blowfish be made into a stream cipher?

If I set L to a "seed" (perhaps 0 for the first block) and R to a counter (again, 0 for the first block) I can XOR the returned R with the plain-text to get my first 32-bits of cipher-text. For the next round, I send back the L that the first round returned, and set R to my counter (1 in this round) and continue on like that for the whole file.

For conventional Blowfish, the encrypted blocks are fed through Blowfish's decryption algorithm to get plaintext; that won't work with my stream cipher. Instead, I basically "encrypt" it again; the values returned by Blowfish, when XOR'd with the ciphertext, will be the plaintext.

So -- I hope I can adequately convey this -- does this work? Or am I "breaking" Blowfish by trying to turn it into a stream cipher?

[Combuster]

Typically algorithms are iterative with one or more steps performed repeatedly, to make sure that every bit of the input is in some way wired to all the bits in the output, and then several times over. If you managed to stick a probe 4 steps into blowfish, then you can probably break it. If you managed to stick a probe 14 steps into blowfish and convince the user to use a weak key, you might be able to recognise that it is blowfish, but not get the data. Blowfish is still defined as 16 rounds. You can't stick probes into an algorithm from the other side of the internet, so these on their own are not issues, though they might provide academics clues about issues to be discovered later. If you look at AES you'll find that it too has such comments. If a yes-or-no answer is what you're after, Blowfish is currently secure.

The rest of your question is not about Blowfish, but about block ciphers in general. This, for example, is data encrypted with AES :

And yet everyone uses it...

Figure out why in the next episode

[davidv1992]

Just as a note on the example given, this is encrypted in Electronic Codebook (ECB) mode, which is known to be weak with any underlying cipher algorithm, as it encrypts every block of N (where N is usually something like 16 or 32 bytes) using the same effective key, leading to patterns if the input data is repetative (such as for images).

In general other block modes are used, though I'm not sure exactly which one is defined as default in the AES standard. What the OP is suggesting seems to be a mix between the counter and output feedback modes, both of which are a lot more sensible. As for what that modification does to the security of blowfish specifically though, I don't know. In general, it is not advisable to roll your own crypto, especially with custom algorithms as it is very difficult to properly judge whether the result is secure.

I would really advise you to stick to the specs of whatever cipher you are using, and preferably try to use an implementation that is well-vetted if possible. There be dragons here if you decide to roll your own

[azblue]

Thank you for your responses davidv1992 and Combuster. I think I'm able to ask more intelligent questions now.

it is not advisable to roll your own crypto, especially with custom algorithms as it is very difficult to properly judge whether the result is secure.

I would really advise you to stick to the specs of whatever cipher you are using, and preferably try to use an implementation that is well-vetted if possible. There be dragons here if you decide to roll your own

Yup! I don't wanna go doing whatever I feel like all willy-nilly; that's more or less guaranteed to be broken, hence my thread.

What the OP is suggesting seems to be a mix between the counter and output feedback modes,

Yup, now that I know about more legitimate variations of block ciphers, I know I should probably stick to one or the other.

Blowfish is still defined as 16 rounds

I feel like this is a pretty stupid question, but I want to be really sure I understand it what a "round" is. I feed plaintext into Blowfish once and get ciphertext, that's one round. I feed that ciphertext back into Blowfish and get new ciphertext, that's 2 rounds. Is this right? Repeat that 14 more times?

The rest of your question is not about Blowfish, but about block ciphers in general.

The Wikipedia page seemed to suggest the variations to block ciphers, such as OFB or CTR, are valid for any block cipher. Did I infer that correctly? In other words, can I be sure I won't break Blowfish's security by turning it into a cipher stream via an established method (ie, OFB or CTR, not the combo I initially made up)?

[nullplan]

I feel like this is a pretty stupid question, but I want to be really sure I understand it what a "round" is. I feed plaintext into Blowfish once and get ciphertext, that's one round. I feed that ciphertext back into Blowfish and get new ciphertext, that's 2 rounds. Is this right? Repeat that 14 more times?

No, that is not it. A round is simply what the algorithm designers say it is. For instance, SHA-3 consists of 24 rounds of five subrounds each. So when you look at an implementation of SHA-3, you will likely see either a loop that runs 24 times, or 24 repetitions of the exact same instructions. The rounds are already in the algorithm.

So in the case of Blowfish, running the encryption already ran all 16 rounds.

The Wikipedia page seemed to suggest the variations to block ciphers, such as OFB or CTR, are valid for any block cipher. Did I infer that correctly? In other words, can I be sure I won't break Blowfish's security by turning it into a cipher stream via an established method (ie, OFB or CTR, not the combo I initially made up)?

Blowfish is a block cipher. That means, it can take 8 bytes of data and a variable length key in and give you 8 bytes of data out. The output fulfills two properties: (1) If you put the output and the same key into the decrypt function, you get your input back out, and (2) it is impossible to distinguish the output from random numbers without the key.

That's not terribly useful on its own: When do you ever want to encrypt exactly 8 bytes of data? So that's what modes of operation are there for. No, they won't tank the security of blowfish on their own, as the security promise of a block cipher has nothing to do with stream encryption. You might need other security promises that you can use the modes of operation along with Blowfish as primitive to fulfill.

It is never enough to say that something is "secure". It is better to say "(insert problem here) cannot happen." In Blowfish, an attacker without the key decrypting a block on its own cannot happen in feasible time. That is its security promise. Of course, improper implementation of a mode of operation can cause the attacker to recover the key or the plain text, but that is not a problem of Blowfish.

And what mode you need, and what other things you need, depend on your application. Though if your threat model includes attackers being able to change ciphertext (as in Internet communication), then please consider the use of authenticated encryption. And put the MAC on the outermost layer and test it first. Common pitfall is to compute the MAC over plaintext. Unfortunately, this allows attackers to recover the plaintext if they can get the receiver to try and decrypt their messages multiple times. Also known as padding oracle. So just compute the MAC over the ciphertext!

[azblue]

Thanks to everyone who responded! I have a much better grasp now