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