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
bram (bram@gawth.com)
Fri, 6 Feb 1998 19:35:04 -0800 (PST)
This is my first post here, so I apologize in advance if I'm commiting any
social faux pas ...
I've written some code which implements ripemd-160 and have run across
what appear to be some differences in what the spec says and how the
reference code works. (I'm going by the documents at
http://www.esat.kuleuven.ac.be/~bosselae/ripemd160.html)
I added the following bit of code to the beginning of compress() in
rmd160.c:
int i;
printf("\n");
for(i = 0;i < 16;i++)
{
printf("%lx ",X[i]);
}
When given 'a' as input, it then generates the following output:
8061 0 0 0 0 0 0 0 0 0 0 0 0 0 8 0
If my understanding of the spec is right, then this really should be:
61800000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 8
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.
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.
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.
The most reasonable scenario I can think of (I might have big/little
endian confused here, so please forgive me) is that the reference code was
written to run on a little endian machine, and both my machine and the one
used for to get the test vector in the ripemd-160 paper are big endian. In
that case, all that's really wrong are the test values in the paper,
although that would still be a major impediment to anyone trying to do a
proper implementation.
I haven't yet tried using any other implementations of ripemd-160 to see
what their behavior is, but I'm going to do that next.
Incidentally, I'm writing this in Java, and have found the JCE (Sun's java
cryptography standard) lacking enough in technical aesthetics that I'm
ignoring it completely.
-Bram
The following archive was created by hippie-mail 7.98617-22 on Fri Aug 21 1998 - 17:14:52 ADT