On 2019-05-17 14:36, Diego Calleja wrote:
El miércoles, 15 de mayo de 2019 19:27:21 (CEST) David Sterba escribió:
Once the code is ready for more checksum algos, we'll pick candidates
and my idea is to select 1 fast (not necessarily strong, but better
than crc32c) and 1 strong (but slow, and sha256 is the candidate at the
moment)
Modern CPUs have SHA256 instructions, it is actually that slow? (not sure how
fast these instructions are)
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...)
If anything, I'd argue for BLAKE2 instead of SHA256 as the 'slow' hash,
as it's got equivalent or better strength but runs significantly faster.
For the fast hash, we should probably be looking more at stuff like
xxhash or murmur3, both of which make CRC32c look slow by comparison (at
least, when you don't have hardware acceleration for the CRC calculations).
