Re: ripemd-160

bram (bram@gawth.com)
Mon, 9 Feb 1998 16:04:52 -0800 (PST)

• Next message: Hamdi Tounsi: "RC5 slower than DES ?"
• Previous message: Robert Hettinga: "Financial Cryptography 1998 Workshop UPDATE"

On Mon, 9 Feb 1998, Eric Young wrote:

> md5 and ripemd-160 are both little endian, sha-1 is bigendian.

This seems to be the problem. After looking over it again, I realize that
the RIPEMD-160 paper never says anything about padding - it's an algorithm
which operates on and outputs integers modulo 2^32. The only thing it says
is 'We assume that the reader is familiar with the structure and notation
of MD4'.

The RFC for MD5, number 1321, is fairly good about specifying that
everything is little-endian, except for the following:

   A 64-bit representation of b (the length of the message before the
   padding bits were added) is appended to the result of the previous
   step.

So which comes first, the more significant or the least significant word?
It doesn't say. Sloppy sloppy sloppy. It's also got the very confusing
language of talking about a 64-bit representation, when what it really
means are two integers modulo 2^32

I personally think that big-endian makes a lot more sense than
little-endian for all these algorithms, because then the bit-ordering
within each byte is the same as the byte-ordering for words as a whole.
How do I know this? In RFC 1321, it says:

   Padding is performed as follows: a single "1" bit is appended to the
   message, and then "0" bits are appended so that the length in bits of
   the padded message becomes congruent to 448, modulo 512.

All the implementations agree that a one followed by three zeros is 8,
hence their bit ordering is big-endian.

> You should also remember that given
> char *input, doing
> *((long *)(input[4]))
> to access the second word is a 'bad thing'.

I'm using java, which just plain doesn't let you do that sort of thing. I
am being good about using the getBytes() method of String instead of
(byte)charAt(x), however. (Irritatingly enough, getBytes() worked
differently in java 1.0)

> 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.

That, at least, is a relief.

Tim Dierks <timd@consensus.com> wrote:

> I'd also like to request that people specify the input and output of
> algorithms as bytes rather than as words. Frequently, the output of one
> stage is used as the input to another. Since most algorithms take byte
> strings as input rather than words, converting the output of one stage
> into the input of another introduces an opportunity for confusion or
> error.

I agree. I have a feeling I'm going to get bitten by this one several more
times. I'd also like to emphasize that the secure hash algorithms specifiy
their input as a series of *bits*, not *bytes*, and that all
implementations which assume a sequence of bytes are in fact only partial
implementations. I'm being fairly good about making notes of this in my
code.

In case anyone's curious, I'm writing this stuff because I work for Eric
Hughes, and am currently responsible for designing and implementing APIs
for his Big Ideas.

-Bram

• Next message: Hamdi Tounsi: "RC5 slower than DES ?"
• Previous message: Robert Hettinga: "Financial Cryptography 1998 Workshop UPDATE"