Looking for two blowfish implementations that produce the same crypts
Cameron Horn
(bonus for Perl) that produce the same crypts, even on different
platforms. Using the raw key of "abcdefgh" and encrypting
"secret\002\002," I get the following results (encoded in Base64):
Current C++ code, Based on an article by Jason Wylie,
Ja...@themediaco.com from www.codeguru.com
Solaris: QUT9sBHtzOk=
Windows: DCFYt1tX75w=
Using Cryptix, a Java product:
DCFYt1tX75w=
Using Perl's Crypt::Blowfish:
DCFYt1tX75w=
Using C code by Paul Kocher:
(Only checked on Windows)
QUT9sBHtzOk=
Code available at request.
Michael Sierchio
OpenSSL.
Cameron Horn
OpenSSL produces QUT9sBHtzOk= on Windows, which may be correct for all
I know. I still cannot generate the same crypt in Java, or Perl.
Which was my original problem.
Michael Amling
> Michael Sierchio <ku...@tenebras.com> wrote in message news:<YRidnQtgTfB...@speakeasy.net>...
>
>>Cameron Horn wrote:
>>
>>>Windows: DCFYt1tX75w=
>>>DCFYt1tX75w=
>>>DCFYt1tX75w=
>>>QUT9sBHtzOk=
>>
>>OpenSSL.
>
> OpenSSL produces QUT9sBHtzOk= on Windows, which may be correct for all
> I know. I still cannot generate the same crypt in Java, or Perl.
> Which was my original problem.
I assume you do not have a pre-existing Blowfish implementation that
you have to be compatible with. So, would it be too suggestive to ask if
you get such discrepancies when using Rijndael?
--Mike Amling
Cameron Horn
This software has been deployed using the first encryption method
described and it would be nice to retain some compatability, even if
only on one platform. I also have a marketing level dependency on
Blowfish. Which I may have to override, given the difficulty I'm
having with such a simple task.
Come on, Blowfish fans! Am I asking too much here? Point out my dumb
mistake, I can take it.
Paul Rubin
> > > Current C++ code, Based on an article by Jason Wylie,
> > > Ja...@themediaco.com from www.codeguru.com
> > > Solaris: QUT9sBHtzOk=
> > > Windows: DCFYt1tX75w=
This looks like it doesn't properly deal with the byte order
difference between the x86 and the sparc. Not too surprising,
since the reference blowfish implemetation operates on two 32-bit
ints rather than on 8 chars.
Michael Amling
Could it be some kind of Endian issue? 2**12 possibilities come to
mind, namely, for each of the key, the plaintext input and the
ciphertext output, try each combination of
A.Reverse the order of bits within a byte.
B.Reverse the order of bytes within each byte pair.
C.Reverse the order of byte pairs within each 32-bit word.
D.Reverse the order of 32-bit words.
--Mike Amling
Cameron Horn
> >>you have to be compatible with. So, would it be too suggestive to ask if
> >>you get such discrepancies when using Rijndael?
> >
> >
> > This software has been deployed using the first encryption method
> > described and it would be nice to retain some compatability, even if
> > only on one platform. I also have a marketing level dependency on
> > Blowfish. Which I may have to override, given the difficulty I'm
> > having with such a simple task.
> >
> > Come on, Blowfish fans! Am I asking too much here? Point out my dumb
> > mistake, I can take it.
>
> Could it be some kind of Endian issue? 2**12 possibilities come to
> mind, namely, for each of the key, the plaintext input and the
> ciphertext output, try each combination of
> A.Reverse the order of bits within a byte.
> B.Reverse the order of bytes within each byte pair.
> C.Reverse the order of byte pairs within each 32-bit word.
> D.Reverse the order of 32-bit words.
I investigated some Endian issues (you missed one - the ordering or
the initialization array), but I'm shooting in the dark at problems I
shouldn't have to deal with.
You've managed to convince me to check out Rijandel.
Michael Amling
> You've managed to convince me to check out Rijandel.
Ah, Rijndael combined with a transposition cipher!
--Mike Amling
Mrsjunecarey
>I'm looking for two blowfish implementations written in C and Java
For a C implementation of Blowfish, why don't you check out OpenBSD:
Since that O/S is meant to be a clean separation of machine independent and
machine dependent code, I imagine their Blowfish implementation would be your
best choice.....
Cheers,
Robin
Eric Young
My this thread has gone on much longer than it should have.
The problem is that the blowfish implementations are correct, even
though they give different answers. The problem is that the blowfish
input is specified as two 32bit numbers.
How do we go from 8 8bit numbers to 2 32bit numbers?
The little-endian people get one answer, the bigendian get the other.
Since the origional test vectors were two 32bit numbers, everyone gets
this part right. It's once they put in the 'unaligned char' -> aligned
32bit' conversion code they get things wrong.
So it is more correct to say that the ecb/cbc code is broken in some of
the implementations. I seem to rember that the 'correct' 8bit -> 32bit
conversion should be little-endian.
eric (who had a similar problem with idea (big-endian) until they
published char based test vectors (instead of short))
Eric Young
> So it is more correct to say that the ecb/cbc code is broken in some of
> the implementations. I seem to rember that the 'correct' 8bit -> 32bit
> conversion should be little-endian.
I should follow up with the comment that some block ciphers can be
implemented as either big-endian or little-endian (DES and AES).
Others, specifically the ones using arithmetic operations, can not
idea big-endian
blowfish little-endian
rc2 little-endian
rc5 little-endian
and the exact endian when used in ecb/cbc etc mode is best defined by
reasonable test vectors.
eric
Tom St Denis
> blowfish little-endian
Are you sure about this? My libtomcrypt blowfish code was checked by
others and reported as working correctly, it also uses big-endian.
Sadly the "reference" code published on counterpane is horribly
non-portable and the paper doesn't specify byte order either [I just
checked].
Tom
Eric Young
hmm... I juat had a look, and yup, you are right, big-endian it is.
My memory is fading... I do remember reading a paper on optimising
blowfish for x86 many years ago, and the endian was the reverse of
what was the accepted standard, so this does make sense (the paper was
using little-endian, while big-endian was the standard). I think I was
remembering this episode.
There are test vectors at http://www.counterpane.com/vectors.txt
Since I supplied them from my version, blowfish must be officially
big-endian :-).
eric