| 1 |
Hello, |
| 2 |
|
| 3 |
I missed some messages in the time I wrote my reply. This also touches |
| 4 |
on some of the points in Mr. Górny's other message about time. |
| 5 |
|
| 6 |
On Fri, Oct 20, 2017 at 6:38 PM, Michał Górny <mgorny@g.o> wrote: |
| 7 |
> W dniu pią, 20.10.2017 o godzinie 00∶20 +0200, użytkownik Francesco |
| 8 |
> Riosa napisał: |
| 9 |
>> 2017-10-19 23:00 GMT+02:00 Michał Górny <mgorny@g.o>: |
| 10 |
>> |
| 11 |
>> > W dniu czw, 19.10.2017 o godzinie 21∶08 +0200, użytkownik Michał Górny |
| 12 |
>> > napisał: |
| 13 |
>> > > |
| 14 |
>> > > 4. The new hashes that are stronger and commonly available are |
| 15 |
>> > > SHA3/Keccak (using sponges) and BLAKE2 (HAIFA). Both are diverse from |
| 16 |
>> > > our current algorithms, so either is a good candidate. The choice of |
| 17 |
>> > > Keccak is purely arbitrary (because it's the winner?). |
| 18 |
>> > > |
| 19 |
>> > |
| 20 |
>> > Actually, a small correction here: we support more implementations |
| 21 |
>> > of SHA3 than BLAKE2, so the first one is less problematic for us. |
| 22 |
>> > |
| 23 |
>> |
| 24 |
>> Not researched in depth but: |
| 25 |
>> B2sum provided by coreutils is quite satisfacting*, it's pretty fast, while |
| 26 |
>> sha-3 is deemed to be slower than sha-2, maybe this could be weighted while |
| 27 |
>> choosing the algorithm wanted. |
| 28 |
>> |
| 29 |
>> Both seem to take advantage of modern multicore CPUs but sha-3 does 11.7 |
| 30 |
>> [cpb]#0 (see #1) while an email seen on the internet say blake2 can reach 1 |
| 31 |
>> [cpb] (see #2) |
| 32 |
>> |
| 33 |
>> #0 cpb = cpu cycles per byte |
| 34 |
>> #1 https://en.wikipedia.org/wiki/SHA-3#Speed |
| 35 |
>> #2 http://www.metzdowd.com/pipermail/cryptography/2016-May/029297.html |
| 36 |
>> * (in my limited experience) |
| 37 |
> |
| 38 |
> I've taken a closer look at BLAKE2 possibilities, and it seems that it's |
| 39 |
> going to be our choice after all. I'm adding dev-python/pyblake2 |
| 40 |
> as a fallback implementation now. |
| 41 |
> |
| 42 |
> Curious enough, after disabling the 'optimized' SSE2 assembly, the plain |
| 43 |
> register implementation is 2.5 times faster than the SSE2 implementation |
| 44 |
> that is used by default, and two times faster than the built-in SHA2 |
| 45 |
> implementation in Python. |
| 46 |
> |
| 47 |
|
| 48 |
It is likely that the register implementation makes better use of the |
| 49 |
data and instruction cache and processor instruction pipeline. For a |
| 50 |
similar reason, functions with larger block sizes tend to run more |
| 51 |
slowly over the same amount of data than their counterparts with |
| 52 |
smaller block sizes. |
| 53 |
|
| 54 |
If speed truly is crucial then it may be a better idea to use one very |
| 55 |
strong hash function and two weaker but faster hash functions. This is |
| 56 |
why I recommended RIPEMD160. If BLAKE2B is used, it may be possible to |
| 57 |
switch SHA512 for SHA256. |
| 58 |
|
| 59 |
It seems important to me to use three hash functions. |
| 60 |
|
| 61 |
Again, though, I think it needs to be pointed out that on slower |
| 62 |
machines the hash time is on the order of tens of seconds. This should |
| 63 |
be negligible compared to the build time. |
| 64 |
|
| 65 |
Cheers, |
| 66 |
R0b0t1 |
Archives