1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
|
Return-Path: <vitteaymeric@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 2727C360
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 24 Feb 2017 15:18:46 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f41.google.com (mail-wm0-f41.google.com [74.125.82.41])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4545AAC
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 24 Feb 2017 15:18:45 +0000 (UTC)
Received: by mail-wm0-f41.google.com with SMTP id v186so17026694wmd.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 24 Feb 2017 07:18:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=subject:to:references:from:message-id:date:user-agent:mime-version
:in-reply-to:content-transfer-encoding;
bh=nJgpML+BmSFmdLUmWqD/VnMEmdAKNnmna7KrQh+Qm8Y=;
b=dnGyFPt77178u04SLQnIEfiFcDeOmZJD6foUEsdzW9nd/TWhAVi+hKZWauVs5p9shN
XO/UEa4073K8VlqT10mm74IWzqDT/Bp6n8MC3RGccKYmuHNGfM1VFagiBdXGQaZLy3MS
W0PoxXIkI8mITgvKWCikVrh4m21jVzKmxVBDD79YeNRQqfPUTJ+IwjUzto9qfERi4YUs
Ml+P1qTXngSXnz3r9W7BkZYUanyvewqevjzCPrYuUw6CtUNOcxmwz3liOEtsjm27NxK7
1MKpT2+BM+VjEtOjrN1CTFqZ82/sJ7PuijiAuYha+dhkXDgpKe4Nd1jfr/RV5tOgI8KT
cQYQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:subject:to:references:from:message-id:date
:user-agent:mime-version:in-reply-to:content-transfer-encoding;
bh=nJgpML+BmSFmdLUmWqD/VnMEmdAKNnmna7KrQh+Qm8Y=;
b=c4nRD6V26uXNZrpmkLes9R6lADNhT+q2i6fkbeue6mVDcf+IdWmZMrzlSGz+Pw65Yd
NzP8xsO7cDTpVNJOicr+HuM3s/hhFEk9AEIp0FFVquGt0MjyGTwy2VP2UhB3IXOBzr6b
CIDYFiOqPcVXfzV556bH5zJHn8sud/o4wgzAJZfqiGK6DaTfeotLytaZ7U/CFLPnewlz
WUwbVThU4QF5bCj3vMsX1pvXS5lYehj/nKCAGuK7un/2AF3j52ZwjvODpRXkd+XMoKLG
mlJszo5aT65KpuSL2ma+uGyOs339hxwJZaaXwzrEt8UiDv0nPMoPL862iFzc32oFkRyl
eAcA==
X-Gm-Message-State: AMke39m89ranONmNeUsUDUWninngrMR2GVzya+4WiPjmUcB+k5zHlwjYz1+iAxmCcg0vRQ==
X-Received: by 10.28.9.13 with SMTP id 13mr3051933wmj.37.1487949523454;
Fri, 24 Feb 2017 07:18:43 -0800 (PST)
Received: from [192.168.1.10] (ANice-654-1-197-68.w86-205.abo.wanadoo.fr.
[86.205.220.68]) by smtp.googlemail.com with ESMTPSA id
63sm2711637wmg.22.2017.02.24.07.18.42
for <bitcoin-dev@lists.linuxfoundation.org>
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Fri, 24 Feb 2017 07:18:42 -0800 (PST)
To: bitcoin-dev@lists.linuxfoundation.org
References: <20170223181409.GA6085@savin.petertodd.org>
<20170223212802.GA7608@savin.petertodd.org>
<76fa5d76-6c54-e13e-7b55-a4409ef536f5@gmail.com>
<1487930694.1528.1.camel@mmci.uni-saarland.de>
From: Aymeric Vitte <vitteaymeric@gmail.com>
Message-ID: <15848c1b-2873-35e8-0588-c636126257df@gmail.com>
Date: Fri, 24 Feb 2017 16:18:43 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.3; rv:45.0) Gecko/20100101
Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <1487930694.1528.1.camel@mmci.uni-saarland.de>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,
RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Fri, 24 Feb 2017 15:22:12 +0000
Subject: Re: [bitcoin-dev] SHA1 collisions make Git vulnerable to attakcs by
third-parties, not just repo maintainers
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Feb 2017 15:18:46 -0000
Not sure that you really read deeply what I sent, because stating that
hashing files continuously instead of hashing the intermediate steps
just gives more latitude to the attacker can't be true when the attacker
has absolutely no control over the past files
I did not write this as a workaround to fix SHA1, which will be dead
soon or later but as maybe some general concept that could possibly help
whatever hash function you are using for objects that are not frozen but
extending (ie the original email stating that trees might be some kind
of worse candidates for collisions reminded me this), indeed it makes no
sense to patch SHA1 or play around, but this kind of proposal could
accompany the defunct
The drawback is that you have to keep the hash state when you close the
latest hash computation in order to start the next one
Then the question is: knowing the hash state, is it as easy to find a
collision between two files that will be computed in the next round than
finding a collision between two files only?
Knowing that you can probably modify the hash state with some
unpredictable patterns
Most likely the answer is: no, it's (astronomically?) more difficult
Please take it as a suggestion that might be explored (ps: I have the
code for this if needed) rather than an affirmation, still amazed as
shown in the few links provided (among others) that each time I raise
this subject nobody really pays attention (what's the use case?, etc)
and by the fact that it's apparently used by only one project in the
world and not supported by any library
Le 24/02/2017 à 11:04, Tim Ruffing via bitcoin-dev a écrit :
> On Fri, 2017-02-24 at 00:57 +0100, Aymeric Vitte via bitcoin-dev wrote:
>> I have not worked on this since some time, so that's just thoughts,
>> but maybe it can render things much more difficult
>> than computing two files until the same hash is found
>>
> You basically rely on the idea that specific collisions are more
> difficult to find. This trick or similar tricks will not help. (And
> actually, the more files you add to the hash, the more freedom you give
> the attacker.)
>
> Even if certain collisions are more difficult to find today (which is
> certainly true), the general rule is that someone will prove you wrong
> in a year.
>
> Even if ignore security entirely, switching to new hash function is
> much simpler trying to fix the usage of a broken hash function.
>
> Relying on SHA1 is hopeless. We have to get rid of it.
>
> Best,
> Tim
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
|
