Engineering comparison of SHA-3 candidates

The primary requirement for a hash function is the security. The SHA-3 Zoo gives an overview of the current state of SHA-3 cryptanalysis. Unfortunately, evaluating the security of an algorithm is lots of hard work. Performing a thorough security evaluation of all SHA-3 candidate algorithms is infeasible.

This page takes a different approach. We first analyze the engineering aspects of each candidate. This includes aspects like performance, memory use, overhead, etc. As the final SHA-3 candidate has to have good engineering properties, it is far more efficient to first select on the engineering properties and only perform the security analysis on the candidates that have good engineering properties. Our primary engineering metrics are


  • Speed on 64-bit CPUs
  • Memory required
  • Overhead for small messages
  • Use of table lookups

We concentrate on software performance on 64-bit code as that is the most relevant metric. By the time SHA-3 standard is selected, 64-bit code will be dominant for performance-sensitive applications. There will be many embedded systems with 32-bit CPUs, but these are rarely performance-critical and have the option to either switch to a 64-bit CPU or add dedicated hardware.

We divide the algorithms into four categories:


Good
Algorithms that we believe make a good standard from an engineering point of view and can be used in all situations where current hash functions are being used. (Algorithms are put in this category until a problem has been identified.)
Fair
Algorithms that have some significant disadvantages but could be made to work in most situations.
Poor
Algorithms that will lead to serious engineering problems when they are used in ways that hash functions are commonly used in practice today.
Broken
Algorithms that have been broken. See the SHA-3 Zoo for details

Within each category the algorithms are sorted in by speed on 64-bit CPUs (where we choose the fastest of the 256/512-bit hash variants).

Please note that this is a very preliminary analysis; most of the data is taken from a quick scan of the submission documentation for each function. Also, it is purely the internal evaluation of the Skein team that we use to select which competitors to spend time on. The data in this table is incomplete, possibly incorrect, and does not necessarily reflect the opinion of any individual Skein team member or any of our employers. If you see gross errors in the table, please let us know and we'll correct them when we have time.

Perfomance data is given in cycles per byte for 256-bit/512-bit hash computation, memory data as memory required (on small machines with few registers) for 256-bit/512-bit hashing.






Algorithm64-bit code32-bit codeMemoryExtrasRemarks
"Good" algorithms, faster than 10 cycles/Byte
Blue Midnight Wish7.32/3.637.64/12.6264/528
TIB37.68/6.2413/4.9532-bit TIB3-512 SSE code by Wei Dai. 64-bit code could probably be as fast as 32-bit code.
Skein7.6/6.121.6/20.1100/200MAC, personalization, PK, KDF, stream cipher, PRNG, randomized, tree, variable output size, block cipherSpeed from conf. presentation
Shabal8.0310.2Speed from conf. presentation
BLAKE8.19/9.299.21/12.53randomizedspeed from email announcement

"Good" algorithms, slower than 10 cycles/Byte
Keccak10/2031/62randomized, personalization, MAC, stream cipher, PRNGSpeed from conf. presentation
SIMD11/1212/13>60 c/B without SSE instructions.
Arirang15/11.320.1/55.2
Luffa13.4/23.213.9/25.5
CHI24/1649/78198/318
JH16.821.3
Grøstl22.2/30.523.1/36.7MACSpeed from conf. presentation
Hamsi25/??Speed from conf. presentation
LANE25.7/14540.5/152
SHAvite-326.7/38.235.3/55
Fugue28/5636/72
Echo28.5/53.532.5/61Much faster with Intel AES instruction

"Fair" algorithms
MD628/4468/106> 700Tree, MACMemory use is not practical on smart cards
SANDstorm37/9562/297Memory > 650 bytes, this is not practical on smart cards. Uses table lookup.
Lesamnta52.7/51.259.2/54.5Slow. Speed from conf. presentation.
SWIFFTX5757(?)Too slow. Performance data unclear.

"Poor" algorithms
CubeHash160200Too slow. Are the speed numbers correct?
FSB324/507Too slow

Broken algorithms
Abacus37.637.6Broken
Aurora15.0/26.919.8/35.5Broken. Speed from conf. presentation.
BlenderBroken
Cheetah9.3/13.615/30Length extension attack. Speed from conf. presentation
Crunch161/446298/862Length extension attack. Too slow.
DCHBroken
Dynamic SHA27.9/47.227.9/47.2Length extension attack, collision
Dynamic SHA221.9/67.221.9/67.3Length extension attack, collision
ECOH>10007500/10000Too slow. Broken.
Edon-R4.30/2.296.46/10.0256/512Broken.
EnRUPTBroken
ESSENSE42/4059/76Slow. Broken.
Khichidi-1Broken
LUX10.2/9.516.7/28.2Speed from conf. presentation. Broken.
MCSSHA-360Broken
MeshHash13.7/18.542.5/67.3Broken.
NaSHA26.5/26.827.3/30.6Broken. Speed from conf. presentation
Sarmal9.4/10.919.2/23.3Broken.
Sgàil61Broken
Spectral HashBroken (near collisions)
StreamHashBroken
TangleBroken
Twister15.8/17.535.8/39.6Broken.
Vortex46.3/56.169.4/90.1Correlation on output bits. Speeds up to < 3 cycles/byte using future Intel CPUs

No longer part of competition
Boole7.68/7.6821.5/21.5MAC, PRNG, stream cipherWithdrawn
HASH 2XDid not make round 1. Broken
Maraca5.3Did not make round 1. Too slow for short messages (e.g. IPsec authentication of a 40-byte packet); requires >6kB memory (impossible on smart cards)
NKS2DDid not make round 1. Broken
Ponic30007000Did not make round 1. Broken, too slow
SHAMATA8/1115/22Withdrawn
WaMM360360Withdrawn
Waterfall16.316.3Withdrawn