RIPEMD-160 Hash Generator

Most hash functions do one thing to each block of data and move on. RIPEMD-160 does two different things to the same block, side by side, and only then adds the answers together. That doubled work made it slower than its rivals on the day it was published. It is also the reason the function is worth looking at closely thirty years later, because the caution turned out to be well placed.

The design is easier to follow as a picture than as a formula: two parallel tracks, a carriage of five words on each, and a junction at the end where they meet.

A European answer to a run of broken hashes

The name comes from a research project. RIPE stands for RACE Integrity Primitives Evaluation, a European Community project whose fact sheet gives a start date of 1 November 1988 and lists a Dutch mathematics centre as coordinator. Its goal was a set of recommended integrity algorithms with precise specifications. One of the things it produced was a hash function called RIPEMD, which its later designers describe as essentially two parallel versions of the earlier MD4, differing only in their constants.

That first RIPEMD did not last. In early 1995 Hans Dobbertin found collisions for versions of it cut down to two rounds out of three, and by the autumn he had extended the technique to full collisions for MD4, which took a few seconds on a personal computer. The designers also worried about raw size. With a 128-bit result, they wrote, a brute-force search for a collision was coming within reach of a well-funded attacker.

So Dobbertin, Antoon Bosselaers and Bart Preneel proposed a replacement. Their updated description carries the date 18 April 1996, and it is frank about its priorities. The aim was a rather conservative design with a high security level, they wrote, instead of pushing the limits of performance with the risk of a redesign a few years later. They changed as little of the old structure as they could, to keep the confidence already built up.

There was an alternative with the same output size. SHA-1 had been published by NIST in 1995. The RIPEMD-160 paper grants that SHA-1 was probably not vulnerable to the known attacks, then adds a pointed sentence: its design criteria were secret. RIPEMD-160 was the 160-bit hash whose reasoning anyone could read.

Two lines, five rounds, one junction

The function works on blocks of 64 bytes, read as 16 words of 32 bits. It keeps a chaining value of five words. For each block, that value is copied twice, once to a left line and once to a right line. Each line then runs 80 steps, so a block costs 160 steps in all.

A single step is small. It adds one register, a Boolean mix of three others, one message word and a constant; rotates the sum left by a set amount; adds a fifth register; and shuffles the registers along. One register is also rotated by ten places on the way, a detail the designers added to block an attack known from MD5.

The 80 steps on a line fall into five rounds of 16, and each round uses every message word exactly once. What differs between the lines is nearly everything else. The left line takes the words in order in its first round, then in orders produced by a fixed permutation. The right line starts from a different order altogether, chosen so that two words close together on the left are at least seven places apart on the right. The five Boolean functions are used in one order on the left and in reverse on the right.

Even the constants are separate, and they are the kind a reader can check. The left line adds the whole-number parts of two to the thirtieth power times the square roots of 2, 3, 5 and 7. The right line uses the cube roots of the same four numbers. Numbers with such a plain origin leave no room for a hidden choice.

At the end the lines meet. Each new chaining word is the sum of one old chaining word, one word from the left and one from the right, in a staggered pattern. The designers explain why the lines were made so unlike each other: the attack on the first RIPEMD showed that changing only the constants between the two was not enough. They expected that one line, or up to three rounds of both, might eventually be attacked, but that the combination would resist.

The same size as SHA-1, built another way

Set beside SHA-1, the family resemblance is plain. Both give 160 bits. Both take 80 steps to go through a block of 16 words. Both start from the same five initial words, a pattern of counting digits that begins 67452301. Both descend from MD4.

The differences are structural. SHA-1 runs a single line. It does not reorder the message words between rounds; it stretches the 16 words into 80 by combining earlier ones, so that every bit of the message touches many steps. RIPEMD-160 keeps the plain reordering of MD4 and buys its safety by doing the work twice in two different ways. It also keeps MD4’s byte order: padding ends with the length of the message, low-order word first.

The price was speed. In the designers’ own measurements on a 90 MHz Pentium, RIPEMD-160 managed 39.8 megabits a second in assembly language against 46.5 for SHA-1, about 15 percent slower.

For a while the two simply stood side by side. An Internet standards-track document of June 2000 specified RIPEMD-160, in keyed form, as one way to authenticate packets. Then their fates parted. Collision attacks went on to undermine SHA-1, and in December 2022 NIST announced that it should be phased out by 31 December 2030. For RIPEMD-160 the published record is of attacks on shortened versions. A 2023 paper reached 36 of the 80 steps, and another later that year reported a colliding pair of messages for 40 of 80 steps, found in practical time. Half the function, in other words, with the full design still standing.

Where Bitcoin put it

The best-known home of RIPEMD-160 today is one line of Bitcoin’s design. The developer reference describes an operation called OP_HASH160, which takes an item, computes SHA-256 of it, and then computes RIPEMD-160 of that result. The usual shorthand is HASH160. For the classic kind of payment, the item is a public key.

The effect is to shrink a key to 20 bytes. A compressed public key is 33 bytes; SHA-256 turns it into 32 bytes, and RIPEMD-160 turns those into 20. The community’s protocol notes give the reason in one line: RIPEMD-160 is used when a shorter hash is desirable, for example when creating an address. The later segregated witness format kept the step, requiring that the HASH160 of the public key match a 20-byte program.

You can follow a published example in the tool above. Choose the public key input and load the example, a key that begins 0250863a. Stage one, SHA-256, gives a value beginning 0b7c28c9. Stage two, RIPEMD-160 of those 32 bytes, gives f54a5851e9372b87810a8e60cdd2e7cfd80b6e31, the value the Bitcoin Wiki prints for the same key. The step view then shows that second stage as 82 pictures: a start, 80 steps and the junction.

It matters what this step is not. Those 20 bytes are not an address. An address adds a version byte and a checksum and is then written in a special alphabet, and none of that is a hash of anything secret. The 20-byte value also says nothing about whether a key is valid or whether anything was ever sent to it.

How long can 160 bits be trusted, and for what

The honest answer depends on the question. For an ideal hash with an output of L bits, NIST gives the expected collision resistance as L/2 bits, because finding any two inputs that agree is far easier than matching one fixed input. For 160 bits that is 80 bits. Finding an input that matches a given digest is a different problem with an expected strength near the full length.

Eighty bits was once the working standard. It no longer is: NIST notes that before 2014 a strength of at least 80 bits was required for federal use and that the figure is now 112. That shift, more than any break, is why new designs pass RIPEMD-160 by. NIST encourages designers to implement SHA-256 at a minimum. The 2024 revision of the OpenPGP standard still lists RIPEMD-160 among its hash algorithms, but says that implementations must not generate signatures with it. OpenSSL 3.0 lists it among the algorithms of its legacy provider.

None of this makes a RIPEMD-160 checksum useless. If the question is whether a download arrived intact, or whether two files are the same, 160 bits is ample. What a checksum cannot do, at any length, is say who produced a file. A digest published beside a download is only as trustworthy as the page it sits on.

And a fast hash of any kind is the wrong tool for storing passwords, since speed is exactly what a guessing attacker wants.

RIPEMD-160 was built by people who had just watched a simpler design fail, and it shows. It spends twice the effort on every block so that a flaw in one line need not sink the whole. The size of its answer has aged; the idea of running two different lines and trusting neither alone has not.