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
|
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 9DD4E9FA
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 24 Feb 2017 17:29:53 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wr0-f172.google.com (mail-wr0-f172.google.com
[209.85.128.172])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id EDB6A214
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 24 Feb 2017 17:29:51 +0000 (UTC)
Received: by mail-wr0-f172.google.com with SMTP id 89so17476026wrr.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 24 Feb 2017 09:29:51 -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=NXvxmJLTsG2k3Ad0AWPCb90vWm6SxIoDxeJJG/O+4VM=;
b=a/yzGVVoQZZ8CmY6W+qLj+s+H4KOwtMToAXIKeWYIEcLbeQhVVE6JsVcOMW9QpddgS
eLLhjF9zl3v2JCSCnkZXAtFr/KMVP239kgbzT6CX5c3D+jKt5JsQdLQZDkSHwd0+hMHk
x3MbdxLR1oyMIu1TqACw4FI1G0eFX9zi+zr1PgDdTRTKeDNxopM7ZFkB5Q38Tacw4XL3
AkUntcNHqJzXNHIC9bj2T13OhGS0kDOlQpLLFdksGJnBRhti28OLK/5sGtQLp2c4Eokt
CGTEbmemqnMWUN3ZbMsCy0IwYsKpIrF/7lCR2ivbvK2AWIt+IKKGpnIT1zFjPlIFihQC
Lc+A==
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=NXvxmJLTsG2k3Ad0AWPCb90vWm6SxIoDxeJJG/O+4VM=;
b=dKoV6hBGA078i3WTEQ5EyFaROyx2n6Dzvj6jJeDLj5fDkIOsmNErv77L+Ai3fp/3u0
8BDg7FHUUWSaHo+cOvhHlM2qF9eml01zwbsA3rHq9PQheyDsZ6yGBX4EkX1yFctPTJBC
SSJ/i9o9GWkzpgX1HiVUxueV6xal//wq0jgvUkzsPpW9xR6n/rVMmNFZyI4F5akhrTva
Nw1auBxB0qJqQt0ngXe6ocwd9Ud9+RvO2Bj+oZFlnrhXUcezgPysZ9+LLUcG+Glsw4CX
dyTdBFHIhZYj+gBV0MFvMndoTUOCfnX6rRjQ2wE7u7+rL/Chtjl2cnm87sJY2v+yFE9F
BKVg==
X-Gm-Message-State: AMke39k0KED4Oo16+9B96N6tiItE3QL+YSWra/9CnH/O9DmS46yjuzpFsVp3NLOj88T+XQ==
X-Received: by 10.223.169.76 with SMTP id u70mr3472011wrc.187.1487957390436;
Fri, 24 Feb 2017 09:29:50 -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
r6sm3132214wmd.4.2017.02.24.09.29.49
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Fri, 24 Feb 2017 09:29:49 -0800 (PST)
To: Tim Ruffing <tim.ruffing@mmci.uni-saarland.de>,
Bitcoin Protocol Discussion <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>
<15848c1b-2873-35e8-0588-c636126257df@gmail.com>
<1487953849.5148.2.camel@mmci.uni-saarland.de>
From: Aymeric Vitte <vitteaymeric@gmail.com>
Message-ID: <b557a0de-2492-80a1-eff7-229503ae382d@gmail.com>
Date: Fri, 24 Feb 2017 18:29:50 +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: <1487953849.5148.2.camel@mmci.uni-saarland.de>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM,
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
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 17:29:53 -0000
??? apparently we are not discussing the same thing
Maybe I did not provide the right links (reading them again I myself
don't find them so clear), see maybe again
https://github.com/whatwg/streams/issues/33#issuecomment-28045860
a - b - c -d
hash(a)
hash(a+b)
etc
But you are not going to rehash from the beginning, then:
update a --> keep the remaining bytes a_ (+ hash state 1) --> digest
a=hash(a)
update a_+b from hash state 1--> keep the remaining bytes b_ (+ hash
state 2) --> digest a_+b=hash(a+b)
etc
Basically that's similar to a real time progressive hash of chunks of a
file that you are streaming and therefore don't know what will come next
(per opposition to hashing a file that you already have), this could
apply to trees
This is different from something like:
hash(a)
hash(hash(a) +hash(b))
etc
There is no initial state, and the attacker can't modify what was
already hashed, to make it more difficult you can probably modify the
hash state N
Le 24/02/2017 à 17:30, Tim Ruffing via bitcoin-dev a écrit :
> On Fri, 2017-02-24 at 16:18 +0100, Aymeric Vitte via bitcoin-dev wrote:
>> 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
> What prevents the attacker to provide different past files when talking
> to parties who are still in the initial state?
>
> 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?
> With the original usage of the hash function, the hash state is always
> the initial state. Now that the attacker has some control over the hash
> state even. In other words, if the original use of the hash function
> was vulnerable, then your scheme is vulnerable for the initial state.
>
> Concrete attack: If you can find x != y with H(x) = H(y), then you can
> also find m, x != y, with H(m||x) = H(m||y), just by setting m = "".
>
> Not sure if this is the right place to discuss that issue though...
>
> 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
|
