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
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
|
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 CEC99C1D
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 Feb 2017 23:57:48 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f50.google.com (mail-wm0-f50.google.com [74.125.82.50])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9B3EA146
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 Feb 2017 23:57:47 +0000 (UTC)
Received: by mail-wm0-f50.google.com with SMTP id r141so2796688wmg.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 Feb 2017 15:57:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=subject:to:references:from:cc:message-id:date:user-agent
:mime-version:in-reply-to;
bh=ujxr8VfX3eO0KFbo6BtxZWFpVS5BqzDkqjDL5ygYeGk=;
b=Jr4PpH5LjNiVndA6nKsH80m7xBwwxLDMX7cOs4BQnTz3GVTRmUR5In5JtvC0ZSlvfC
RGNP1+Wfc5o3sTiLGD6O5Y/48CfZseV6YqeYeR7sCh6sZV63uvl3eGyVY/Hgl8AqA+dJ
OLPreoGHEl8Aoxvgqp9SA8z5ll5XdUBiguz9YRnpfNDFv2JtvWfOCDIEC8QDITkEGNQU
t4UxxgSP60uRbhZuPjzu8TkI2DH3+7hGnJvhS5VYvLzD5qLZnW2QkMNVPO1zq+pSGA3C
8U3mICs0C2DbZiAoUSmQz3q1BEsDFEbLKkqaS7k37gqFNa0Ho9HDuhySWsKXdNv75Yh0
0eEg==
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:cc:message-id:date
:user-agent:mime-version:in-reply-to;
bh=ujxr8VfX3eO0KFbo6BtxZWFpVS5BqzDkqjDL5ygYeGk=;
b=q2VmrgVxDp6F8f96blT14Obp64Zqp4jvbdISL0KHRX6xzKOpdCN6MeXCK35OrkfQ26
6RIAU/IEzXe5Hlc31TzjsYdFe5E89CBvN7ncLhSNTbSo5f5TnUzDDtymrSRE0BpG+gq3
R3KY8zRFmTUPYlWKYxjCVrsy35NUyvzjVLE4V/ICYoJJ9vKgzjYTIG6BYRKNMGFvnoTU
+CRl5O9gnZbdjiyoOfMo1Tw7//odpv+qCtYS0s111j1B3SyBE/4vUFjdrLcageMUnZUf
XGR7WamfbL8Df5G9Ol1Gz0+8wOw3PMlDLs10JuaQ7Hu9BIf0Axl1krDVx7wIA02/jyus
fAcA==
X-Gm-Message-State: AMke39lnARTFVhytuOAgzv1KgAkGmUtTMA/gK/euPfYJQHcvPAxgekm41UO79/EYkK+Bxw==
X-Received: by 10.28.87.85 with SMTP id l82mr138234wmb.135.1487894266149;
Thu, 23 Feb 2017 15:57:46 -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
v128sm44594wmv.2.2017.02.23.15.57.45
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Thu, 23 Feb 2017 15:57:45 -0800 (PST)
To: bitcoin-dev@lists.linuxfoundation.org
References: <20170223181409.GA6085@savin.petertodd.org>
<20170223212802.GA7608@savin.petertodd.org>
From: Aymeric Vitte <vitteaymeric@gmail.com>
Message-ID: <76fa5d76-6c54-e13e-7b55-a4409ef536f5@gmail.com>
Date: Fri, 24 Feb 2017 00:57:45 +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: <20170223212802.GA7608@savin.petertodd.org>
Content-Type: multipart/alternative;
boundary="------------C9D09EED127694C30CF36C99"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
RCVD_IN_DNSWL_NONE autolearn=ham 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 00:04:41 +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: Thu, 23 Feb 2017 23:57:48 -0000
This is a multi-part message in MIME format.
--------------C9D09EED127694C30CF36C99
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Maybe not, unlike frozen objects (certificates, etc), trees are supposed
to extend
Then you can perform progressive hash operations on the objects, ie
instead of hashing the intermediate hash of the objects you do it
continuously (ie instead of hashing the hash of hash file a + hash file
b + hash file c, wait for file d and then do the same, instead hash(file
a + file b + file c), when d comes compute the hash of (file a + file b
+ file c + file d), which implies each time to keep the intermediary
hash state because you are not going to recompute everything from the
beginning)
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
The only living example I know implementing this is the Tor protocol,
fact apparently unknown, this is probably why nobody cares and nobody is
willing to take it into account (please follow bwd/fwd [1] and see [2]),
this is not existing in any crypto implementations, unless you hack into
it, and this applies to progressive encryption too
[1]
https://lists.w3.org/Archives/Public/public-webcrypto-comments/2013Feb/00=
18.html
[2] https://github.com/whatwg/streams/issues/33#issuecomment-28554151
Le 23/02/2017 =E0 22:28, Peter Todd via bitcoin-dev a =E9crit :
> On Thu, Feb 23, 2017 at 01:14:09PM -0500, Peter Todd via bitcoin-dev wr=
ote:
>> Worth noting: the impact of the SHA1 collison attack on Git is *not* l=
imited
>> only to maintainers making maliciously colliding Git commits, but also=
>> third-party's submitting pull-reqs containing commits, trees, and espe=
cially
>> files for which collisions have been found. This is likely to be explo=
itable in
>> practice with binary files, as reviewers aren't going to necessarily n=
otice
>> garbage at the end of a file needed for the attack; if the attack can =
be
>> extended to constricted character sets like unicode or ASCII, we're in=
trouble
>> in general.
>>
>> Concretely, I could prepare a pair of files with the same SHA1 hash, t=
aking
>> into account the header that Git prepends when hashing files. I'd then=
submit
>> that pull-req to a project with the "clean" version of that file. Once=
the
>> maintainer merges my pull-req, possibly PGP signing the git commit, I =
then take
>> that signature and distribute the same repo, but with the "clean" vers=
ion
>> replaced by the malicious version of the file.
> Thinking about this a bit more, the most concerning avenue of attack is=
likely
> to be tree objects, as I'll bet you you can construct tree objs with ga=
rbage at
> the end that many review tools don't pick up on. :(
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--=20
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.o=
rg
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
--------------C9D09EED127694C30CF36C99
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>Maybe not, unlike frozen objects (certificates, etc), trees are
supposed to extend</p>
<p>Then you can perform progressive hash operations on the objects,
ie instead of hashing the intermediate hash of the objects you do
it continuously (ie instead of hashing the hash of hash file a +
hash file b + hash file c, wait for file d and then do the same,
instead hash(file a + file b + file c), when d comes compute the
hash of (file a + file b + file c + file d), which implies each
time to keep the intermediary hash state because you are not going
to recompute everything from the beginning)</p>
<p>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<br>
</p>
<p>The only living example I know implementing this is the Tor
protocol, fact apparently unknown, this is probably why nobody
cares and nobody is willing to take it into account (please follow
bwd/fwd [1] and see [2]), this is not existing in any crypto
implementations, unless you hack into it, and this applies to
progressive encryption too<br>
</p>
<p>[1] <a class="moz-txt-link-freetext"
href="https://lists.w3.org/Archives/Public/public-webcrypto-comments/2013Feb/0018.html">https://lists.w3.org/Archives/Public/public-webcrypto-comments/2013Feb/0018.html</a>
</p>
<pre wrap="">[2] <a class="moz-txt-link-freetext" href="https://github.com/whatwg/streams/issues/33#issuecomment-28554151">https://github.com/whatwg/streams/issues/33#issuecomment-28554151</a></pre>
<br>
<div class="moz-cite-prefix">Le 23/02/2017 à 22:28, Peter Todd via
bitcoin-dev a écrit :<br>
</div>
<blockquote cite="mid:20170223212802.GA7608@savin.petertodd.org"
type="cite">
<pre wrap="">On Thu, Feb 23, 2017 at 01:14:09PM -0500, Peter Todd via bitcoin-dev wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Worth noting: the impact of the SHA1 collison attack on Git is *not* limited
only to maintainers making maliciously colliding Git commits, but also
third-party's submitting pull-reqs containing commits, trees, and especially
files for which collisions have been found. This is likely to be exploitable in
practice with binary files, as reviewers aren't going to necessarily notice
garbage at the end of a file needed for the attack; if the attack can be
extended to constricted character sets like unicode or ASCII, we're in trouble
in general.
Concretely, I could prepare a pair of files with the same SHA1 hash, taking
into account the header that Git prepends when hashing files. I'd then submit
that pull-req to a project with the "clean" version of that file. Once the
maintainer merges my pull-req, possibly PGP signing the git commit, I then take
that signature and distribute the same repo, but with the "clean" version
replaced by the malicious version of the file.
</pre>
</blockquote>
<pre wrap="">
Thinking about this a bit more, the most concerning avenue of attack is likely
to be tree objects, as I'll bet you you can construct tree objs with garbage at
the end that many review tools don't pick up on. :(
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
bitcoin-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>
<a class="moz-txt-link-freetext" href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Zcash wallets made simple: <a class="moz-txt-link-freetext" href="https://github.com/Ayms/zcash-wallets">https://github.com/Ayms/zcash-wallets</a>
Bitcoin wallets made simple: <a class="moz-txt-link-freetext" href="https://github.com/Ayms/bitcoin-wallets">https://github.com/Ayms/bitcoin-wallets</a>
Get the torrent dynamic blocklist: <a class="moz-txt-link-freetext" href="http://peersm.com/getblocklist">http://peersm.com/getblocklist</a>
Check the 10 M passwords list: <a class="moz-txt-link-freetext" href="http://peersm.com/findmyass">http://peersm.com/findmyass</a>
Anti-spies and private torrents, dynamic blocklist: <a class="moz-txt-link-freetext" href="http://torrent-live.org">http://torrent-live.org</a>
Peersm : <a class="moz-txt-link-freetext" href="http://www.peersm.com">http://www.peersm.com</a>
torrent-live: <a class="moz-txt-link-freetext" href="https://github.com/Ayms/torrent-live">https://github.com/Ayms/torrent-live</a>
node-Tor : <a class="moz-txt-link-freetext" href="https://www.github.com/Ayms/node-Tor">https://www.github.com/Ayms/node-Tor</a>
GitHub : <a class="moz-txt-link-freetext" href="https://www.github.com/Ayms">https://www.github.com/Ayms</a></pre>
</body>
</html>
--------------C9D09EED127694C30CF36C99--
|
