1 |
On Mon, Oct 23, 2017 at 01:33:15PM +0200, Michał Górny wrote: |
2 |
> Dnia 23 października 2017 10:16:38 CEST, "Robin H. Johnson" <robbat2@g.o> napisał(a): |
3 |
> >On Fri, Oct 20, 2017 at 05:21:47PM -0500, R0b0t1 wrote: |
4 |
> >> In general I do not mind updating the algorithms used, but I do feel |
5 |
> >> it is important to keep at least three present. Without at least |
6 |
> >three |
7 |
> >> (or a larger odd number) it is not possible to break a tie. |
8 |
> >> |
9 |
> >> That may ultimately be beside the point, as any invalid hashes should |
10 |
> >> result in the user contacting the developers or doing something else, |
11 |
> >> but it is hard to know. |
12 |
> >I'm dropping the rest of your email about about exactly which hashes |
13 |
> >we're bike-shedding, to focus on the number of hashes. |
14 |
> > |
15 |
> >I agree with your opinion to have three hashes present, and I've give a |
16 |
> >solid rationale with historical references. |
17 |
> > |
18 |
> >The major reason to have 3 hashes, is as a tie-breaker, to detect if |
19 |
> >there was a bug in the hash somehow (implementation, |
20 |
> >compiler/assembler, |
21 |
> >interpreter), and not the distfile. This also strongly suggests that 3 |
22 |
> >hashes should have different construction. |
23 |
> |
24 |
> 1. How are you planning to distinguish a successful attack against two hashes from a bug in one of them? |
25 |
> |
26 |
> 2. Even if you do, what's the value of knowing that? |
27 |
[BOBO06] is relevant research here, I cited it in the work that went into |
28 |
GLEP59, the last time we updated the hashes. The less-technical explanation of it is: |
29 |
"If you can express the output of H1(x)H2(x) in LESS bits than the combined |
30 |
output size of H1,H2, then the attacks get a little bit easier" |
31 |
|
32 |
Some important pieces from it: |
33 |
[J04] "showed that the concatenation of two Merkle-Damgard functions is not |
34 |
much more secure than the individual functions.", but this holds ONLY if |
35 |
the hash functions chosen are of the same construction (MD). |
36 |
Choosing hashes with different constructions (Merkle-Damgard, HAIFA, |
37 |
Sponge) is important, and given a black box environment, |
38 |
|
39 |
The original mail reached the same approximate decision, just to look |
40 |
for diverse hashes, but decided that 2 was enough. |
41 |
|
42 |
Q: What are the odds of a simultaneous successful attack against two hashes? |
43 |
A: IDK, but if the hash functions are truly independent, it must be provably |
44 |
lower than the odds of an attack against a single hash. |
45 |
|
46 |
Q: What's the big difference between a bug and a successful attack in a hash? |
47 |
A: Bugs are more likely initially, and attacks come later. |
48 |
|
49 |
All of that said, is there really a significant long-term gain in |
50 |
multiple hashes? (setting aside the short-term advantage in a transition |
51 |
period for changing hashes) |
52 |
|
53 |
> >2009: https://bugs.gentoo.org/255131 |
54 |
> >app-crypt/mhash-0.9.9 segfaults with NULL digest in whirlpool/snefru |
55 |
> >(portage uses python-mhash bindings) |
56 |
> How is this one relevant? AFAICS it did not cause wrong result. |
57 |
It output inconsistent garbage for the hash in at least one case that I |
58 |
recall. |
59 |
|
60 |
[BOBO06] Boneh, D. and Boyen, X. (2006). |
61 |
"On the Impossibility of Efficiently Combining Collision Resistant Hash Functions"; |
62 |
Proceedings of CRYPTO 2006, Dwork, C. (Ed.); |
63 |
Lecture Notes in Computer Science 4117, pp. 570-583. |
64 |
Available online from: http://crypto.stanford.edu/~dabo/abstracts/hashing.html |
65 |
|
66 |
[J04] Joux A. (2004). |
67 |
"Multicollisions in Iterated Hash Functions. Application to Cascaded Constructions". |
68 |
In: Franklin M. (eds) Advances in Cryptology – CRYPTO 2004. CRYPTO 2004. |
69 |
Lecture Notes in Computer Science, vol 3152. Springer, Berlin, Heidelberg |
70 |
https://www.iacr.org/archive/crypto2004/31520306/multicollisions.pdf |
71 |
|
72 |
-- |
73 |
Robin Hugh Johnson |
74 |
Gentoo Linux: Dev, Infra Lead, Foundation Asst. Treasurer |
75 |
E-Mail : robbat2@g.o |
76 |
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 |
77 |
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136 |