Hello, I missed some messages in the time I wrote my reply. This also touches on some of the points in Mr. Górny's other message about time.
On Fri, Oct 20, 2017 at 6:38 PM, Michał Górny <mgo...@gentoo.org> wrote: > 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 <mgo...@gentoo.org>: >> >> > 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. > It is likely that the register implementation makes better use of the data and instruction cache and processor instruction pipeline. For a similar reason, functions with larger block sizes tend to run more slowly over the same amount of data than their counterparts with smaller block sizes. If speed truly is crucial then it may be a better idea to use one very strong hash function and two weaker but faster hash functions. This is why I recommended RIPEMD160. If BLAKE2B is used, it may be possible to switch SHA512 for SHA256. It seems important to me to use three hash functions. Again, though, I think it needs to be pointed out that on slower machines the hash time is on the order of tens of seconds. This should be negligible compared to the build time. Cheers, R0b0t1
