W dniu pią, 20.10.2017 o godzinie 00∶20 +0200, użytkownik Francesco Riosa napisał: > 2017-10-19 23:00 GMT+02:00 Michał Górny <[email protected]>: > > > W dniu czw, 19.10.2017 o godzinie 21∶08 +0200, użytkownik Michał Górny > > napisał: > > > > > > 4. The new hashes that are stronger and commonly available are > > > SHA3/Keccak (using sponges) and BLAKE2 (HAIFA). Both are diverse from > > > our current algorithms, so either is a good candidate. The choice of > > > Keccak is purely arbitrary (because it's the winner?). > > > > > > > Actually, a small correction here: we support more implementations > > of SHA3 than BLAKE2, so the first one is less problematic for us. > > > > Not researched in depth but: > B2sum provided by coreutils is quite satisfacting*, it's pretty fast, while > sha-3 is deemed to be slower than sha-2, maybe this could be weighted while > choosing the algorithm wanted. > > Both seem to take advantage of modern multicore CPUs but sha-3 does 11.7 > [cpb]#0 (see #1) while an email seen on the internet say blake2 can reach 1 > [cpb] (see #2) > > #0 cpb = cpu cycles per byte > #1 https://en.wikipedia.org/wiki/SHA-3#Speed > #2 http://www.metzdowd.com/pipermail/cryptography/2016-May/029297.html > * (in my limited experience)
I've taken a closer look at BLAKE2 possibilities, and it seems that it's going to be our choice after all. I'm adding dev-python/pyblake2 as a fallback implementation now. Curious enough, after disabling the 'optimized' SSE2 assembly, the plain register implementation is 2.5 times faster than the SSE2 implementation that is used by default, and two times faster than the built-in SHA2 implementation in Python. -- Best regards, Michał Górny
