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