Other Directory Sites: SeekWonder | Directory Owners Forum
The following archive was created by hippie-mail 7.98617-22 on Fri Aug 21 1998 - 17:14:52 ADT
Eric Young (eay@cryptsoft.com)
Mon, 9 Feb 1998 13:56:34 +1000 (EST)
On Fri, 6 Feb 1998, bram wrote:
> Normally I'd assume I was having some kind of big endian/little endian
> problem on my own machine, but I just wrote some code to do shs and used
> the exact same code to do the padding, and it gives completely valid
> results. Also, if the reference code is designed for the wrong type of
> architecture, I'd expect the last two numbers in the first line of numbers
> above to be 80000000 0 instead of 8 0.
Having recently implemented ripemd-160 in C and x86 asm, I can probably
comment :-).
md5 and ripemd-160 are both little endian, sha-1 is bigendian.
> Also, some rearrangement is done on the finished hash - when the reference
> code is done hashing, the value it has for a is e8894b25, but it's printed
> out as 254b89e8.
In this case, we are talking about a word, so this is independant of the byte
order. You are probably printing it as %02x%02x%02x%02x, after chopping the
work back into bytes. Print it as a %08X word and it will probably match :-).
Given
0x01, 0x02, 0x03, 0x04, on a bigendian algorithm, the 'long int' would be
0x01020304. On a little endian algorithm, it would be
0x04030201. This is not a case of the byte order of the machine, but
the byte order of the algorithm. You should also remember that given
char *input, doing
*((long *)(input[4]))
to access the second word is a 'bad thing'. It works for x86, but most
risc cpu's will give an unaligned access error if 'input' is not word aligned.
While this is normally the case, for my SSLv2 implementation, this was often
not true.
DES used to be interesting because they actually used big-endian bit ordering,
so the the parity bit for the key is in what we normally think of as the
LSB of a byte. Having implemented most popular ciphers and digests, I
personally would like more people implementing them to specify which endian
the algorithm is. My initial IDEA implementation was wrong because I assumed
little-endian instead of big-endian when converting short->char.
Whenever the internal representation of the data is not characters, the
conversion should really be stated.
> Does anyone else have any experience implementing ripemd-160? The
> reference code gives the same results for the test suite on my machine are
> given in the paper, so the problem isn't having to do with my machine.
> I've got sha-1 working with the same padding code, so it's doubtful that
> that code doesn't follow the spec. I can make my code give the same
> results as the reference code does with just some tweaking in the padding
> and printing parts, so the problem also isn't anywhere in the 'meat' of
> the algorithm.
See above. In summery, remember that the byte order is an algorithm issue,
not a CPU one, unless you are being 'bad' and directly copying bytes into
words which should be avoided anyway.
eric
The following archive was created by hippie-mail 7.98617-22 on Fri Aug 21 1998 - 17:14:52 ADT