SHA-3 (Keccak)

Posted Sep 30, 2020 21:02 UTC (Wed) by wittenberg (subscriber, #4473)
Parent article: Mercurial planning to transition away from SHA-1

Why was SHA-3 (Keccak) not considered? It is completely different from SHA-1 and SHA-2, and supports hashes of various lengths.

--David

SHA-3 (Keccak)

Posted Oct 3, 2020 1:24 UTC (Sat) by murukesh (subscriber, #97031) [Link] (1 responses)

Phrases like "[SHA2-256] is widely supported and some CPUSs have hardware acceleration for that" and "the third category would be picking one of the more modern speed-optimized variants of the SHA3 finalists" makes me think their priorities meant SHA3 itself didn't end up high on the shortlist. The benchmarks in the first post did include SHA3:

I've attached basic benchmark numbers below. The asm variant is using
whatever my Threadripper supports in terms of low-level primitives, e.g.
AVX2 and the SHA extension, either from OpenSSL (BLAKE2, SHA2, SHA3) or
the reference implementations (K12, BLAKE3, BLAKE3*). Test case was
hashing a large file (~7GB). 

BLAKE2s256 (asm)  13.8s
SHA2-256   (asm)   4.5s
SHA2-256   (C)    28.0s
SHA3-256   (asm)  16.7s
SHA3-256   (C)    19.8s
K12        (asm)   5.9s
K12        (C)     9.2s
BLAKE3     (asm)   4.1s
BLAKE3     (C)    10.1s
BLAKE3*    (asm)   5.5s
BLAKE3*    (C)    13.8s

SHA3 is not winning any prizes there.

SHA-3 (Keccak)

Posted Oct 8, 2020 3:50 UTC (Thu) by scientes (guest, #83068) [Link]

The approval of SHA3 as such is frowned upon as only creating confusion and incompatibility with SHA2, without clear benefits.