On Fri, May 17, 2019 at 08:36:23PM +0200, 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...) BLAKE2 looks as a good candidate. I have a glue code to export it as the crypto module so we'll be able to test it at least. I'm not sure about SHA3 due to the performance reasons, it comes out slower than SHA256 and that one is already considered slow.
