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
|
Return-Path: <tim.ruffing@mmci.uni-saarland.de>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 4DF4F360
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 24 Feb 2017 16:30:55 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from hera.mpi-klsb.mpg.de (infao0809.mpi-klsb.mpg.de [139.19.1.49])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8171619F
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 24 Feb 2017 16:30:54 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
d=mmci.uni-saarland.de; s=mail200803;
h=Content-Transfer-Encoding:Mime-Version:Content-Type:References:In-Reply-To:Date:To:From:Subject:Message-ID;
bh=ZgBGplayPbjJ+RJq4MoO7ufBf1AarYma62AepXZm6ks=;
b=lpfemylAl7Fcdb6X469xVEYcWeZJ/N8XZHeu1TzCL6wuJiW+BoK4H+RFLaNnXssuFt+H7DifPwG9nuAw+dkcFu7WzbUVLBqYN1g12qixLNSHXMBr5b4vdempgq0E6wt0RVgk2mjTvADo956iC+kpiQ8dWD85GLlsrfdOem8Y6M0=;
Received: from sam.mpi-klsb.mpg.de ([139.19.86.26]:47618)
by hera.mpi-klsb.mpg.de (envelope-from
<tim.ruffing@mmci.uni-saarland.de>)
with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128)
(Exim 4.80) id 1chIle-0001vO-1p
for bitcoin-dev@lists.linuxfoundation.org;
Fri, 24 Feb 2017 17:30:51 +0100
Received: from mbpc48.cs.uni-saarland.de ([134.96.225.161]:34330)
by sam.mpi-klsb.mpg.de (envelope-from
<tim.ruffing@mmci.uni-saarland.de>)
with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) id 1chIld-0007U0-Ry
for bitcoin-dev@lists.linuxfoundation.org;
Fri, 24 Feb 2017 17:30:49 +0100
Message-ID: <1487953849.5148.2.camel@mmci.uni-saarland.de>
From: Tim Ruffing <tim.ruffing@mmci.uni-saarland.de>
To: bitcoin-dev@lists.linuxfoundation.org
Date: Fri, 24 Feb 2017 17:30:49 +0100
In-Reply-To: <15848c1b-2873-35e8-0588-c636126257df@gmail.com>
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>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.22.5
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-MPI-Local-Sender: true
X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, RCVD_IN_DNSWL_MED 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 16:30:55 -0000
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
|
