3 ms·
A) I am not sure I'd say blake2 obsoletes blake, and certainly blake3 does not obsolete b2. They are a family, but still different algorithms. B) blake3, afaik
by kortex 5y ago
A) I am not sure I'd say blake2 obsoletes blake, and certainly blake3 does not obsolete b2. They are a family, but still different algorithms.
B) blake3, afaik, is not yet as thoroughly vetted as b2.
C) I think some of the hype around b3 is deserved. It's crazy fast. If you don't care about crypto at all (e.g. file dedup), it's absolutely phenomenal. But the main downside of B3 right now is just novelty. Cryto algos are like fine wines.
D) I don't know enough about Keccak vs Blake, but just because Blake2 has received less scrutiny, doesn't mean it's insufficient. I'm sure there are tradeoffs that the kernel editors have chosen.
E: here's a link to some discussion:
https://crypto.stackexchange.com/questions/31674/what-advantages-does-keccak-sha-3-have-over-blake2 https://crypto.stackexchange.com/questions/31674/what-advant...
- tptacek 5y agoBlake2 is already in lib/crypto in the kernel (it's needed for WireGuard, by the same author as this change); SHA3 and Blake3 are not. It's probably that simple.
- rincebrain 5y agoBLAKE3 is crazy fast...on x86, with extremely performant implementations using SIMD instructions present. On other platforms, where people haven't written such (or, IME, even on ARM when using their NEON version), it's nothing to write home about.