1 |
W dniu wto, 24.10.2017 o godzinie 06∶04 +0200, użytkownik Michał Górny |
2 |
napisał: |
3 |
> W dniu pon, 23.10.2017 o godzinie 21∶00 +0000, użytkownik Robin H. |
4 |
> Johnson napisał: |
5 |
> > On Mon, Oct 23, 2017 at 01:33:15PM +0200, Michał Górny wrote: |
6 |
> > > Dnia 23 października 2017 10:16:38 CEST, "Robin H. Johnson" <robbat2@g.o> napisał(a): |
7 |
> > > > On Fri, Oct 20, 2017 at 05:21:47PM -0500, R0b0t1 wrote: |
8 |
> > > > > In general I do not mind updating the algorithms used, but I do feel |
9 |
> > > > > it is important to keep at least three present. Without at least |
10 |
> > > > |
11 |
> > > > three |
12 |
> > > > > (or a larger odd number) it is not possible to break a tie. |
13 |
> > > > > |
14 |
> > > > > That may ultimately be beside the point, as any invalid hashes should |
15 |
> > > > > result in the user contacting the developers or doing something else, |
16 |
> > > > > but it is hard to know. |
17 |
> > > > |
18 |
> > > > I'm dropping the rest of your email about about exactly which hashes |
19 |
> > > > we're bike-shedding, to focus on the number of hashes. |
20 |
> > > > |
21 |
> > > > I agree with your opinion to have three hashes present, and I've give a |
22 |
> > > > solid rationale with historical references. |
23 |
> > > > |
24 |
> > > > The major reason to have 3 hashes, is as a tie-breaker, to detect if |
25 |
> > > > there was a bug in the hash somehow (implementation, |
26 |
> > > > compiler/assembler, |
27 |
> > > > interpreter), and not the distfile. This also strongly suggests that 3 |
28 |
> > > > hashes should have different construction. |
29 |
> > > |
30 |
> > > 1. How are you planning to distinguish a successful attack against two hashes from a bug in one of them? |
31 |
> > > |
32 |
> > > 2. Even if you do, what's the value of knowing that? |
33 |
> > |
34 |
> > [BOBO06] is relevant research here, I cited it in the work that went into |
35 |
> > GLEP59, the last time we updated the hashes. The less-technical explanation of it is: |
36 |
> > "If you can express the output of H1(x)H2(x) in LESS bits than the combined |
37 |
> > output size of H1,H2, then the attacks get a little bit easier" |
38 |
> > |
39 |
> > Some important pieces from it: |
40 |
> > [J04] "showed that the concatenation of two Merkle-Damgard functions is not |
41 |
> > much more secure than the individual functions.", but this holds ONLY if |
42 |
> > the hash functions chosen are of the same construction (MD). |
43 |
> > Choosing hashes with different constructions (Merkle-Damgard, HAIFA, |
44 |
> > Sponge) is important, and given a black box environment, |
45 |
> > |
46 |
> > The original mail reached the same approximate decision, just to look |
47 |
> > for diverse hashes, but decided that 2 was enough. |
48 |
> > |
49 |
> > Q: What are the odds of a simultaneous successful attack against two hashes? |
50 |
> > A: IDK, but if the hash functions are truly independent, it must be provably |
51 |
> > lower than the odds of an attack against a single hash. |
52 |
> |
53 |
> We're talking about really huge (→∞) numbers here. It's not a 'random' |
54 |
> attack against one hash. It's an attack that allows to sneak a malicious |
55 |
> code with unchanged file size (since we store that too), and no apparent |
56 |
> side effects (what's the point of spending up that much resources |
57 |
> if the user is going to notice?). |
58 |
> |
59 |
> > Q: What's the big difference between a bug and a successful attack in a hash? |
60 |
> > A: Bugs are more likely initially, and attacks come later. |
61 |
> |
62 |
> Sounds like an entirely abstract point in time ;-). |
63 |
> |
64 |
> > All of that said, is there really a significant long-term gain in |
65 |
> > multiple hashes? (setting aside the short-term advantage in a transition |
66 |
> > period for changing hashes) |
67 |
> |
68 |
> No, and that's my point. One hash is perfectly fine. |
69 |
> |
70 |
> Two hashes are useful for transition purposes. If we take two fast |
71 |
> hashes (e.g. proposed SHA512 + BLAKE2B which have similar speed), |
72 |
> we can use 2 threads to prevent the speed loss (except for old single- |
73 |
> core machines). |
74 |
> |
75 |
> Three hashes don't give any noticeable advantage. If we want a diverse |
76 |
> construct, we take SHA3. SHA3 is slower than SHA2 + BLAKE2 combined, so |
77 |
> even with 3 threaded computation it's going to be slower. |
78 |
|
79 |
Oh, and most notably, the speed loss will be mostly visible to users. |
80 |
An attacker would have to compute the additional hashes only |
81 |
if the fastest hash already matched, i.e. rarely. Users will have to |
82 |
compute them all the time. |
83 |
|
84 |
-- |
85 |
Best regards, |
86 |
Michał Górny |