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
|
Return-Path: <gavinandresen@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 7AF6AB5C
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 12 Jan 2016 12:08:22 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com
[209.85.217.170])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7DEE413B
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 12 Jan 2016 12:08:21 +0000 (UTC)
Received: by mail-lb0-f170.google.com with SMTP id cl12so53718439lbc.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 12 Jan 2016 04:08:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:content-type; bh=Bs3pVU9r26hFrHHwJq1jWRxeuN9qntqgP3xx0ZrQgHY=;
b=ZymnU9ad7ZztvKAojUhBkHWRWrP7cc2hCrKTWFCo4q5AiZWtKonBt/yJLssWJqKI92
m1jonWf0Y19hu2a1cXASqhKsdp/dD5uEXieWoOIDIARjNXgSMX1lQTjx0qlrcwRJIntr
G+XoN3hlnAEiCgjmKBPf7thsbE7fPb0U+ucCqFjQ/l3LL5GcTLJiJwKJnNgy4Zb9q30B
NAbuKFGdWhwbBMZ8ZhazB6ZyQP6tn7sQh+de7CK/Og4QWxHRdd6AP9hT1ioz6yLcvb7m
WuBfnkDs/0qZimYAdUc4YQj87dErXzj0Ycj1LJeggwMqVhWXMP1yagrKOAzLeXc+ISCU
V9mQ==
MIME-Version: 1.0
X-Received: by 10.112.157.69 with SMTP id wk5mr48512435lbb.74.1452600499104;
Tue, 12 Jan 2016 04:08:19 -0800 (PST)
Received: by 10.25.79.208 with HTTP; Tue, 12 Jan 2016 04:08:18 -0800 (PST)
In-Reply-To: <CAE-z3OVuAMdpZb+-C4JS_6FEreFohOMAsWpepgE1L5YoBOw4iA@mail.gmail.com>
References: <CABsx9T3aTme2EQATamGGzeqNqJkUcPGa=0LVidJSRYNznM-myQ@mail.gmail.com>
<CAPg+sBhH0MODjjp8Avx+Fy_UGqzMjUq_jn3vT3oH=u3711tsSA@mail.gmail.com>
<8760z4rbng.fsf@rustcorp.com.au>
<C4B5B9F1-9C53-45BC-9B30-F572C78096E3@mattcorallo.com>
<8737u8qnye.fsf@rustcorp.com.au>
<CABsx9T1gmz=sr_sEEuy8BQU6SXdmi58O30rzRWNW=0Ej98fi4A@mail.gmail.com>
<20160108153329.GA15731@sapphire.erisian.com.au>
<CABsx9T3MfndREm9icE-TUF58zsRZ5YsBMvUAMy4E-MmYWxWV=A@mail.gmail.com>
<CAE-z3OUMRivWPVA+3BgC_95MGYBHN34+hoo6xfCu_gNeLFVknA@mail.gmail.com>
<CAE-z3OVuAMdpZb+-C4JS_6FEreFohOMAsWpepgE1L5YoBOw4iA@mail.gmail.com>
Date: Tue, 12 Jan 2016 07:08:18 -0500
Message-ID: <CABsx9T3UTSnLx_BGfMTrQB1=vR9Bdd8OJvSXy=++-_=wfv7+uw@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a11c2abd6c0041e052921e87f
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,LOTS_OF_MONEY,
RCVD_IN_DNSWL_LOW 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: Tue, 12 Jan 2016 13:15:39 +0000
Subject: Re: [bitcoin-dev] Time to worry about 80-bit collision attacks or
not?
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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: Tue, 12 Jan 2016 12:08:22 -0000
--001a11c2abd6c0041e052921e87f
Content-Type: text/plain; charset=UTF-8
I'm convinced-- it is a good idea to worry about 80-bit collision attacks
now.
Thanks to all the people smarter than me who contributed to this
discussion, I learned a lot about collision attacks that I didn't know
before.
Would this be a reasonable "executive summary" :
If you are agreeing to lock up funds with somebody else, and they control
what public key to use, you are susceptible to collision attacks.
It is very likely an 80-bit-collision-in-ten-minutes attack will cost less
than $1million in 10 to twenty years (possibly sooner if there are crypto
breaks in that time).
If you don't trust the person with whom you're locking up funds and you're
locking up a significant amount of money (tens of millions of dollars
today, tens of thousands of dollars in a few years):
Then you should avoid using pay-to-script-hash addresses and instead use
the payment protocol and "raw" multisig outputs.
AND/OR
Have them give you a hierarchical deterministic (BIP32) seed, and derive a
public key for them to use.
----------
Following the security in depth and validate all input secure coding
principles would mean doing both-- avoid p2sh AND have all parties to a
transaction exchange HD seeds, add randomness, and use the resulting public
keys in the transaction.
--
--
Gavin Andresen
--001a11c2abd6c0041e052921e87f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I'm convinced-- it is a good idea to worry about 80-bi=
t collision attacks now.<div><br></div><div>Thanks to all the people smarte=
r than me who contributed to this discussion, I learned a lot about collisi=
on attacks that I didn't know before.</div><div><br></div><div>Would th=
is be a reasonable "executive summary" :</div><div><br></div><div=
>If you are agreeing to lock up funds with somebody else, and they control =
what public key to use, you are susceptible to collision attacks.</div><div=
><br></div><div>It is very likely an 80-bit-collision-in-ten-minutes attack=
will cost less than $1million in 10 to twenty years (possibly sooner if th=
ere are crypto breaks in that time).</div><div><br></div><div>If you don=
9;t trust the person with whom you're locking up funds and you're l=
ocking up a significant amount of money (tens of millions of dollars today,=
tens of thousands of dollars in a few years):</div><div><br></div><div>The=
n you should avoid using pay-to-script-hash addresses and instead use the p=
ayment protocol and "raw" multisig outputs.</div><div><br></div><=
div>AND/OR</div><div><br></div><div>Have them give you a hierarchical deter=
ministic (BIP32) seed, and derive a public key for them to use.</div><div><=
br></div><div><br></div><div>----------</div><div><br></div><div>Following =
the security in depth and validate all input secure coding principles would=
mean doing both-- avoid p2sh AND have all parties to a transaction exchang=
e HD seeds, add randomness, and use the resulting public keys in the transa=
ction.</div><div><br></div><div><br></div><div class=3D"gmail_extra">-- <br=
><div class=3D"gmail_signature">--<br>Gavin Andresen<br></div>
</div></div>
--001a11c2abd6c0041e052921e87f--
|
