Hi Ævar,
On Mon, 11 Jun 2018, Ævar Arnfjörð Bjarmason wrote:
> On Sat, Jun 09 2018, brian m. carlson wrote:
>
> [Expanding the CC list to what we had in the last "what hash" thread[1]
> last year].
>
> > == Discussion of Candidates
> >
> > I've implemented and tested the following algorithms, all of which are
> > 256-bit (in alphabetical order):
> >
> > * BLAKE2b (libb2)
> > * BLAKE2bp (libb2)
> > * KangarooTwelve (imported from the Keccak Code Package)
> > * SHA-256 (OpenSSL)
> > * SHA-512/256 (OpenSSL)
> > * SHA3-256 (OpenSSL)
> > * SHAKE128 (OpenSSL)
> >
> > I also rejected some other candidates. I couldn't find any reference or
> > implementation of SHA256×16, so I didn't implement it. I didn't
> > consider SHAKE256 because it is nearly identical to SHA3-256 in almost
> > all characteristics (including performance).
> >
> > I imported the optimized 64-bit implementation of KangarooTwelve. The
> > AVX2 implementation was not considered for licensing reasons (it's
> > partially generated from external code, which falls foul of the GPL's
> > "preferred form for modifications" rule).
> >
> > === BLAKE2b and BLAKE2bp
> >
> > These are the non-parallelized and parallelized 64-bit variants of
> > BLAKE2.
> >
> > Benefits:
> > * Both algorithms provide 256-bit preimage resistance.
> >
> > Downsides:
> > * Some people are uncomfortable that the security margin has been
> > decreased from the original SHA-3 submission, although it is still
> > considered secure.
> > * BLAKE2bp, as implemented in libb2, uses OpenMP (and therefore
> > multithreading) by default. It was no longer possible to run the
> > testsuite with -j3 on my laptop in this configuration.
> >
> > === Keccak-based Algorithms
> >
> > SHA3-256 is the 256-bit Keccak algorithm with 24 rounds, processing 136
> > bytes at a time. SHAKE128 is an extendable output function with 24
> > rounds, processing 168 bytes at a time. KangarooTwelve is an extendable
> > output function with 12 rounds, processing 136 bytes at a time.
> >
> > Benefits:
> > * SHA3-256 provides 256-bit preimage resistance.
> > * SHA3-256 has been heavily studied and is believed to have a large
> > security margin.
> >
> > I noted the following downsides:
> > * There's a lack of a availability of KangarooTwelve in other
> > implementations. It may be the least available option in terms of
> > implementations.
> > * Some people are uncomfortable that the security margin of
> > KangarooTwelve has been decreased, although it is still considered
> > secure.
> > * SHAKE128 and KangarooTwelve provide only 128-bit preimage resistance.
> >
> > === SHA-256 and SHA-512/256
> >
> > These are the 32-bit and 64-bit SHA-2 algorithms that are 256 bits in
> > size.
> >
> > I noted the following benefits:
> > * Both algorithms are well known and heavily analyzed.
> > * Both algorithms provide 256-bit preimage resistance.
> >
> > == Implementation Support
> >
> > |===
> > | Implementation | OpenSSL | libb2 | NSS | ACC | gcrypt | Nettle| CL |
> > | SHA-1 | 🗸 | | 🗸 | 🗸 | 🗸 | 🗸 | {1} |
> > | BLAKE2b | f | 🗸 | | | 🗸 | | {2} |
> > | BLAKE2bp | | 🗸 | | | | | |
> > | KangarooTwelve | | | | | | | |
> > | SHA-256 | 🗸 | | 🗸 | 🗸 | 🗸 | 🗸 | {1} |
> > | SHA-512/256 | 🗸 | | | | | 🗸 | {3} |
> > | SHA3-256 | 🗸 | | | | 🗸 | 🗸 | {4} |
> > | SHAKE128 | 🗸 | | | | 🗸 | | {5} |
> > |===
> >
> > f: future version (expected 1.2.0)
> > ACC: Apple Common Crypto
> > CL: Command-line
> >
> > :1: OpenSSL, coreutils, Perl Digest::SHA.
> > :2: OpenSSL, coreutils.
> > :3: OpenSSL
> > :4: OpenSSL, Perl Digest::SHA3.
> > :5: Perl Digest::SHA3.
> >
> > === Performance Analysis
> >
> > The test system used below is my personal laptop, a 2016 Lenovo ThinkPad
> > X1 Carbon with an Intel i7-6600U CPU (2.60 GHz) running Debian unstable.
> >
> > I implemented a test tool helper to compute speed much like OpenSSL
> > does. Below is a comparison of speeds. The columns indicate the speed
> > in KiB/s for chunks of the given size. The runs are representative of
> > multiple similar runs.
> >
> > 256 and 1024 bytes were chosen to represent common tree and commit
> > object sizes and the 8 KiB is an approximate average blob size.
> >
> > Algorithms are sorted by performance on the 1 KiB column.
> >
> > |===
> > | Implementation | 256 B | 1 KiB | 8 KiB | 16 KiB |
> > | SHA-1 (OpenSSL) | 513963 | 685966 | 748993 | 754270 |
> > | BLAKE2b (libb2) | 488123 | 552839 | 576246 | 579292 |
> > | SHA-512/256 (OpenSSL) | 181177 | 349002 | 499113 | 495169 |
> > | BLAKE2bp (libb2) | 139891 | 344786 | 488390 | 522575 |
> > | SHA-256 (OpenSSL) | 264276 | 333560 | 357830 | 355761 |
> > | KangarooTwelve | 239305 | 307300 | 355257 | 364261 |
> > | SHAKE128 (OpenSSL) | 154775 | 253344 | 337811 | 346732 |
> > | SHA3-256 (OpenSSL) | 128597 | 185381 | 198931 | 207365 |
> > | BLAKE2bp (libb2; threaded) | 12223 | 49306 | 132833 | 179616 |
> > |===
> >
> > SUPERCOP (a crypto benchmarking tool;
> > https://bench.cr.yp.to/results-hash.html) has also benchmarked these
> > algorithms. Note that BLAKE2bp is not listed, KangarooTwelve is k12,
> > SHA-512/256 is equivalent to sha512, SHA3-256 is keccakc512, and SHAKE128 is
> > keccakc256.
> >
> > Information is for kizomba, a Kaby Lake system. Counts are in cycles
> > per byte (smaller is better; sorted by 1536 B column):
> >
> > |===
> > | Algorithm | 576 B | 1536 B | 4096 B | long |
> > | BLAKE2b | 3.51 | 3.10 | 3.08 | 3.07 |
> > | SHA-1 | 4.36 | 3.81 | 3.59 | 3.49 |
> > | KangarooTwelve | 4.99 | 4.57 | 4.13 | 3.86 |
> > | SHA-512/256 | 6.39 | 5.76 | 5.31 | 5.05 |
> > | SHAKE128 | 8.23 | 7.67 | 7.17 | 6.97 |
> > | SHA-256 | 8.90 | 8.08 | 7.77 | 7.59 |
> > | SHA3-256 | 10.26 | 9.15 | 8.84 | 8.57 |
> > |===
> >
> > Numbers for genji262, an AMD Ryzen System, which has SHA acceleration:
> >
> > |===
> > | Algorithm | 576 B | 1536 B | 4096 B | long |
> > | SHA-1 | 1.87 | 1.69 | 1.60 | 1.54 |
> > | SHA-256 | 1.95 | 1.72 | 1.68 | 1.64 |
> > | BLAKE2b | 2.94 | 2.59 | 2.59 | 2.59 |
> > | KangarooTwelve | 4.09 | 3.65 | 3.35 | 3.17 |
> > | SHA-512/256 | 5.54 | 5.08 | 4.71 | 4.48 |
> > | SHAKE128 | 6.95 | 6.23 | 5.71 | 5.49 |
> > | SHA3-256 | 8.29 | 7.35 | 7.04 | 6.81 |
> > |===
> >
> > Note that no mid- to high-end Intel processors provide acceleration.
> > AMD Ryzen and some ARM64 processors do.
> >
> > == Summary
> >
> > The algorithms with the greatest implementation availability are
> > SHA-256, SHA3-256, BLAKE2b, and SHAKE128.
> >
> > In terms of command-line availability, BLAKE2b, SHA-256, SHA-512/256,
> > and SHA3-256 should be available in the near future on a reasonably
> > small Debian, Ubuntu, or Fedora install.
> >
> > As far as security, the most conservative choices appear to be SHA-256,
> > SHA-512/256, and SHA3-256.
> >
> > The performance winners are BLAKE2b unaccelerated and SHA-256 accelerated.
>
> This is a great summary. Thanks.
>
> In case it's not apparent from what follows, I have a bias towards
> SHA-256. Reasons for that, to summarize some of the discussion the last
> time around[1], and to add more details:
>
> == Popularity
>
> Other things being equal we should be biased towards whatever's in the
> widest use & recommended fon new projects.
>
> I fear that if e.g. git had used whatever at time was to SHA-1 as
> BLAKE2b is to SHA-256 now, we might not even know that it's broken (or
> had the sha1collisiondetection work to fall back on), since researchers
> are less likely to look at algorithms that aren't in wide use.
>
> SHA-256 et al were published in 2001 and has ~20k results on Google
> Scholar, compared to ~150 for BLAKE2b[4], published in 2008 (but ~1.2K
> for "BLAKE2").
>
> Between the websites of Intel, AMD & ARM there are thousands of results
> for SHA-256 (and existing in-silicon acceleration). There's exactly one
> result on all three for BLAKE2b (on amd.com, in the context of a laundry
> list of hash algorithms in some presentation.
>
> Since BLAKE2b lost the SHA-3 competition to Keccak it seems impossible
> that it'll get ever get anywhere close to the same scrutiny or support
> in silicon as one of the SHA families.
>
> Which brings me to the next section...
>
> == Hardware acceleration
>
> The only widely deployed HW acceleration is for the SHA-1 and SHA-256
> from the SHA-2 family[5], but notably nothing from the newer SHA-3
> family (released in 2015).
>
> It seems implausible that anything except SHA-3 will get future HW
> acceleration given the narrow scope of current HW acceleration
> v.s. existing hash algorithms.
>
> As noted in the thread from last year[1] most git users won't even
> notice if the hashing is faster, but it does matter for some big users
> (big monorepos), so having the out of purchasing hardware to make things
> faster today is great, and given how these new instruction set
> extensions get rolled out it seems inevitable that this'll be available
> in all consumer CPUs within 5-10 years.
>
> == Age
>
> Similar to "popularity" it seems better to bias things towards a hash
> that's been out there for a while, i.e. it would be too early to pick
> SHA-3.
>
> The hash transitioning plan, once implemented, also makes it easier to
> switch to something else in the future, so we shouldn't be in a rush to
> pick some newer hash because we'll need to keep it forever, we can
> always do another transition in another 10-15 years.
>
> == Conclusion
>
> For all the above reasons I think we should pick SHA-256.
>
> 1. https://public-inbox.org/git/87y3ss8n4h.fsf@xxxxxxxxx/#t
> 2. https://github.com/cr-marcstevens/sha1collisiondetection
> 3. https://scholar.google.nl/scholar?hl=en&as_sdt=0%2C5&q=SHA-256&btnG=
> 4. https://scholar.google.nl/scholar?hl=en&as_sdt=0%2C5&q=BLAKE2b&btnG=
> 5. https://en.wikipedia.org/wiki/Intel_SHA_extensions
I agree with that reasoning.
More importantly, my cryptography researcher colleagues agree with this
assessment, and I do trust them quite a bit (you know one of them very
well already as we, ahem, *might* be using his code for SHA-1 collision
detection all the time now *cough, cough*).
Ciao,
Dscho
