(Cryptix Application Note #1 --July 1997)
Return to the Application Notes Index or the FAQ or the Overview
Antoon Bosselaers, co-author of RIPEMD-160, has extensively reviewed the performance of the MD4, MD5, SHA, RIPEMD, RIPEMD-128 and RIPEMD-160 hash functions ([DBP96], [BGV96] and [Bos97]) on Pentium processors using highly optimised Assembler and C code. The following table gives performance indices of these hash algorithms (all except RIPEMD) based on Bosselaers latest implementations as published in his report [Bos97]:
Algorithm |
Rate |
Relative |
---|---|---|
MD4 |
190.6 |
100 |
MD5 |
133.1 |
70 |
SHA-1 |
54.9 |
29 |
RIPEMD-128 |
76.9 |
40 |
RIPEMD-160 |
45.2 |
24 |
I conducted a limited test (1 MB) using Cryptix's Java implementations of MD4, RIPEMD-128 and RIPEMD-160, and used Sun's MD5 and SHA available in the JDK sun package (source code in TestMDs). These are the result of this test obtained with a Pentium 133MHz running the JDK 1.1.3 Virtual Machine on a Windows95, both with and without the JIT compiler included in Sun's Performance Pack.
Table-2: Cryptix implementation performance with JDK 1.1.3 | ||||||
|
Without JIT compiler |
With JIT compiler | ||||
---|---|---|---|---|---|---|
Algorithm |
Time |
Rate |
Relative |
Time |
Rate |
Relative |
MD4 |
5,220 |
1,569 |
100 |
770 |
10,638 |
100 |
MD5 (1) |
7,630 |
1,073 |
68 |
880 |
9,309 |
87 |
MD5 (2) |
10,930 |
788 |
50 |
1,590 |
5,152 |
48 |
SHA-1 |
7,910 |
1,035 |
65 |
770 |
10,638 |
100 |
RIPEMD-128 |
8,780 |
933 |
59 |
1,210 |
6,770 |
63 |
RIPEMD-160 |
12,200 |
671 |
42 |
1,320 |
6,206 |
58 |
The figures for the MD5 (1) line were obtained with a special version of Sun's MD5. I decompiled and re-compiled it with its engineUpdate() method redefined as public to allow access from the test class, and changed the place of the synchronisation lock to be on the whole class instead of it being local for some methods. This was done to have comparable execution times.
The MD5 (2) is the normal sun.security.provider.MD5. Figures for this version are slower than what they should be, mainly due to the inability to directly call the engineUpdate() method --it is defined as protected and hence only calls to update() from the MessageDigest superclass can be invoked. The difference between the two lines is mostly the penalty paid for mapping update(byte[]) from the MessageDigest superclass to MD5 class's engineUpdate(byte[], int, int) and back.
All found on Antoon Bosselaers' web site.
Copyright © 1996-1997 Systemics Ltd
on behalf of the Cryptix Development Team.
All rights reserved.
Cryptix is a trademark of Systemics Ltd.