Re: [PATCH 00/17] Add support for SHA-256 checksums

[Adam Borowski <kilobyte@angband.pl>]

On Fri, May 17, 2019 at 09:07:03PM +0200, Johannes Thumshirn wrote:
> On Fri, May 17, 2019 at 08:36:23PM +0200, Diego Calleja wrote:
> > If btrfs needs an algorithm with good performance/security ratio, I would 
> > suggest considering BLAKE2 [1]. It is based in the BLAKE algorithm that made 
> > to the final round in the SHA3 competition, it is considered pretty secure 
> > (above SHA2 at least), and it was designed to take advantage of modern CPU 
> > features and be as fast as possible - it even beats SHA1 in that regard. It is 
> > not currently in the kernel but Wireguard uses it and will add an 
> > implementation when it's merged (but Wireguard doesn't use the crypto layer 
> > for some reason...)
> 
> SHA3 is on my list of other candidates to look at for a performance
> evaluation. As for BLAKE2 I haven't done too much research on it and I'm not a
> cryptographer so I have to trust FIPS et al.

"Trust FIPS" is the main problem here.  Until recently, FIPS certification
required implementing this nice random generator:
    https://en.wikipedia.org/wiki/Dual_EC_DRBG

Thus, a good part of people are reluctant to use hash functions chosen by
NIST (and published as FIPS).

BLAKE2 is also a good deal faster on most hardware:
    https://bench.cr.yp.to/results-sha3.html
Even with sha_ni, SHA256 wins only on Zen AMDs: sha_ni equipped Intels have
superior SIMD thus BLAKE2 is still faster.  And without sha_ni, the
difference is drastic.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ Latin:   meow 4 characters, 4 columns,  4 bytes
⣾⠁⢠⠒⠀⣿⡁ Greek:   μεου 4 characters, 4 columns,  8 bytes
⢿⡄⠘⠷⠚⠋  Runes:   ᛗᛖᛟᚹ 4 characters, 4 columns, 12 bytes
⠈⠳⣄⠀⠀⠀⠀ Chinese: 喵   1 character,  2 columns,  3 bytes <-- best!