| 1 |
W dniu pią, 20.10.2017 o godzinie 17∶42 +0200, użytkownik Paweł Hajdan, |
| 2 |
Jr. napisał: |
| 3 |
> On 19/10/2017 21:08, Michał Górny wrote: |
| 4 |
> > Considering all arguments made so far, I'd like to propose changing: |
| 5 |
> > manifest-hashes = SHA256 SHA512 WHIRLPOOL |
| 6 |
> > to: |
| 7 |
> > manifest-hashes = SHA512 SHA3_512 |
| 8 |
> |
| 9 |
> +1, fine for me |
| 10 |
> |
| 11 |
> > 1. The main argument for using multiple hashes is to prevent the (very |
| 12 |
> > unlikely) possibility that if a weakness is discovered in one of |
| 13 |
> > the hashes, the other would still hold. This is given by using two |
| 14 |
> > algorithms; more than two do not increase security significantly, while |
| 15 |
> > they do increase performance cost. |
| 16 |
> |
| 17 |
> Curious, do we have any measurements/estimates of the performance cost? |
| 18 |
> |
| 19 |
|
| 20 |
Not specific but I think it's pretty simple, assuming we don't get any |
| 21 |
multithread-friendly algorithms. |
| 22 |
|
| 23 |
With a single thread serial processing of all hashes, it's just sum of |
| 24 |
times involved in every hash, i.e. Th = T1 + T2 + T3 + ... You'd have to |
| 25 |
get some numbers to get something smarter out of it. |
| 26 |
|
| 27 |
If we assume we can do N threads, then cost of N algorithms is equal to |
| 28 |
the slowest of them all. Which implies that having N algorithms is |
| 29 |
fastest on systems capable of at least N threads. |
| 30 |
|
| 31 |
Taking a random comparison [1], it seems that SHA3/512 is 3-5 times |
| 32 |
slower than SHA2/512. If we take that as conclusive, the relative times |
| 33 |
would be: |
| 34 |
|
| 35 |
a. single hash: |
| 36 |
|
| 37 |
SHA512 - 1 |
| 38 |
SHA3_512 - 3-5 |
| 39 |
|
| 40 |
b. both hashes: |
| 41 |
|
| 42 |
serial - 4-6 |
| 43 |
parallel - 3-5 |
| 44 |
|
| 45 |
[1]:http://wireilla.com/papers/ijcis/V3N3/3313ijcis01.pdf |
| 46 |
|
| 47 |
-- |
| 48 |
Best regards, |
| 49 |
Michał Górny |
Archives