From: bill@carpenter.ORG (WJCarpenter)

I've stumbled across a minor problem with the "bfsh-con.zip"
implementation of Blowfish that you make available from the
Counterpane web site.  I know this probably isn't your code (I have no
idea who Jim Conger is), but since you pass out copies, I thought
you'd like to know about it.

It's not a crypto bug, it's a data byte-ordering problem.  It probably
doesn't affect crypto strength.  Because of the byte ordering problem,
the code is probably compatible with other copies of itself, but not
with Blowfish implementations that give the results in the sample test
vectors on your site.  

(For comparison, I used the Sun JCE 1.2.1 Blowfish and the Cryptix.org
re-implementation of JCE, and those do match the test vector results
[for cases I spot-checked].  Actually, it was trying to get these two
implementations to talk to each other that led me down this path.
It's amazing how much a little byte ordering difference in a crypto
implementation can totally toast interoperability.  :-)

To use the Conger code with data encrypted by these other
implementations, you have to jump through these minor hoops:

* The key data is used as-is.  No reordering is necessary.

* The bytes of the encrypted data get reversed in sets of 4.  In other
  words, if I give you "ABCD EFGH", you should change it to "DCBA
  HGFE" before decryption.
  
* After you get the decrypted bytes out, repeat the reversal in sets
  of 4 (same chunk of code should work).

There are #defines in the Conger code to deal with byte-ordering
things, but I guess they don't do the right things.  (I actually
iterated through all of them, including making up some new ones just
to test, and none of the alternate settings worked.)  My guess is that
it has something to do with the reordering code working on chunks of 4
bytes while Blowfish overall works on chunks of 8 bytes.  I didn't
really pursue it after I found the above workaround/recipe.

BTW, all my testing of the Conger code was on Windows 2000 Server (as
was my testing of the Java implementations).  Code was compiled with
Visual C++ from Visual Studio 6.  I exclusively used ECB mode with no
padding (my test data was always a multiple of 8 bytes).
-- 
bill@carpenter.ORG (WJCarpenter)    PGP 0x91865119
38 95 1B 69 C9 C6 3D 25    73 46 32 04 69 D6 ED F3