Does knowing common prefixes help crack blowfish? I have strings that are if the form:

 {static data}{changing data}


The beginning static data part is around 20 characters and is common to all strings. The last part is around 5 characters and is different for each string.

The string is encrypted using blowfish (from xjava.security.Cipher) with a fixed initialization vector and a fixed key. Can the fact that the beginning data is unchanging be used as an effective exploit to help break the encryption?

[Edit] Updated to use correct terminology and add a little more information.
The answer depends a great deal about what you're actually doing.

For one, "salt" is not a commonly used term if you are encrypting; public data that is used to modify how the encryption is done is commonly termed an "IV" (Initialization Vector).  However, "salt" is the common term for public data that modifies how a hash is generated.  The distinction between "encrypting" and "hashing" is that hashing can't be undone; given a hash, it's impractical for anyone (even for someone with the key) to generate the original string.

I'll see if I can go through the various possibilities:


If you are actually doing hashing (for example, hashing a password so that you can recognize it if someone enters it), well, what salt does is it protects in two different ways:


If you have two different users which have the same password, differing salts will disguise the fact that the passwords are the same.
It prevents an attacker from getting an attacking multiple passwords at once (for example, by hashing a test password, and seeing if that hash is anyone on the system).


Not doing salt isn't fatal, but generally it is easy enough to warrant the protection it does provide.

And, if you are using PHP's crypt() function (as woliveirajr guesses), well, they always provide a salt -- if you don't provide one, the crypt() function will pick one for you (which is a good thing).  So, in this case, you don't have a problem at all.

In addition, having some fixed text at the start of the string you're hashing doesn't help the attacker at all (if it does, the hash function is seriously broken).
If you are actually doing encryption (that is, you expect someone to be able to decrypt the encrypted string), well, you've got a problem.  Most encryption mechanisms do take an IV, and bad things happen if you keep it constant; exactly what those bad things are depends on which 'encryption mode' you are using:


If you use CBC mode (with a fixed IV), the attacker will be able to see if two encrypted messages are identical up to 8*N bytes in length (for any N).  In your example (assuming the fixed part is exactly 20 bytes long), then this means that the attacker can tell if the first 4 bytes of the variable part of two different strings happen to be the same.
If you use CTR mode (with a fixed IV), it gets a lot worse.  The attacker is able to compute the exclusive-or of any two strings; this will likely allow him to deduce the value of the strings.


In both cases, the correct fix would be to generate distinct IVs, and include those in the encrypted messages.

Also, having some fixed text at the start of the string really doesn't affect the security.  If you pick IVs correctly, it won't affect things at all; if you use a fixed IV, well, fixed text doesn't hurt much.