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
|
Return-Path: <watsonbladd@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id AC1B8F47
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 8 Jan 2016 01:27:03 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-yk0-f180.google.com (mail-yk0-f180.google.com
[209.85.160.180])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 24A1A165
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 8 Jan 2016 01:27:03 +0000 (UTC)
Received: by mail-yk0-f180.google.com with SMTP id k129so324957560yke.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 07 Jan 2016 17:27:03 -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
:cc:content-type;
bh=au+EjLJgw7D40aW1IUByh8+SdpdV7oPNowoxuujTMbA=;
b=sAEJ0Jtxn1p5qjkAVzCQLEVWTgpnCP22R+XZ+uECmACDbXyf9GqtrO7zcU477VKHlk
NcS3bWZji9DuQ0X25c31lrxQ6sQzxfcCdN/4tn4UmnPOd7ZBFd8ZK23wxutsFvHKlSP6
U9aBoxQG+9VSinvFRLGKTxfeTdnZ91DbbhsAsxuP65n3MHuNfnHsLE/jqPrajwqHsOxJ
qatOM2uWXS4SrWTbzDvr1h1fj18BmlIeRAfZMj0ONAHRwtYNL3YyB3fak4tRIh+NxiZm
vim9xTU5sBegNDi3WDMJYwt7kE5nhp/5+oERaF3BxmpFXBGu7WhPKr92/3rJPZYAVxHG
4lZQ==
MIME-Version: 1.0
X-Received: by 10.13.226.137 with SMTP id l131mr89750189ywe.239.1452216422344;
Thu, 07 Jan 2016 17:27:02 -0800 (PST)
Received: by 10.13.216.150 with HTTP; Thu, 7 Jan 2016 17:27:02 -0800 (PST)
Received: by 10.13.216.150 with HTTP; Thu, 7 Jan 2016 17:27:02 -0800 (PST)
In-Reply-To: <CABsx9T1cPYorAo=u5YjA1tOoN5GNQpb_hT-ZTG9G9Hp88GgAMA@mail.gmail.com>
References: <CABsx9T3aTme2EQATamGGzeqNqJkUcPGa=0LVidJSRYNznM-myQ@mail.gmail.com>
<CAPg+sBhH0MODjjp8Avx+Fy_UGqzMjUq_jn3vT3oH=u3711tsSA@mail.gmail.com>
<CABsx9T1cPYorAo=u5YjA1tOoN5GNQpb_hT-ZTG9G9Hp88GgAMA@mail.gmail.com>
Date: Thu, 7 Jan 2016 17:27:02 -0800
Message-ID: <CACsn0cn9ijwc+SzLqVgd+2RvL1xAdu9XdwVqU-zjy=2Qt9J0bg@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: multipart/alternative; boundary=001a114fe252fdadab0528c87bb3
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,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: Fri, 08 Jan 2016 02:38:30 +0000
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
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: Fri, 08 Jan 2016 01:27:03 -0000
--001a114fe252fdadab0528c87bb3
Content-Type: text/plain; charset=UTF-8
On Jan 7, 2016 5:22 PM, "Gavin Andresen via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> On Thu, Jan 7, 2016 at 6:52 PM, Pieter Wuille <pieter.wuille@gmail.com>
wrote:
>>
>> Bitcoin does have parts that rely on economic arguments for security or
privacy, but can we please stick to using cryptography that is up to par
for parts where we can? It's a small constant factor of data, and it
categorically removes the worry about security levels.
>
> Our message may have crossed in the mod queue:
>
> "So can we quantify the incremental increase in security of
SHA256(SHA256) over RIPEMD160(SHA256) versus the incremental increase in
security of having a simpler implementation of segwitness?"
There are several clever ways to exploit even chosen prefix collisions
using the scripting language. One could search for collisions where one
message is some data and the other is a jump over a critical check.
>
> I believe the history of computer security is that implementation errors
and sidechannel attacks are much, much more common than brute-force breaks.
KEEP IT SIMPLE.
Ask the Iranian nuclear program. Or those brainwallet users.
>
> (and a quibble: "do a 80-bit search for B and C such that H(A and B) =
H(B and C)" isn't enough, you have to end up with a C public key for which
you know the corresponding private key or the attacker just succeeds in
burning the funds)
>
>
> --
> --
> Gavin Andresen
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--001a114fe252fdadab0528c87bb3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr"><br>
On Jan 7, 2016 5:22 PM, "Gavin Andresen via bitcoin-dev" <<a h=
ref=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linu=
xfoundation.org</a>> wrote:<br>
><br>
> On Thu, Jan 7, 2016 at 6:52 PM, Pieter Wuille <<a href=3D"mailto:pi=
eter.wuille@gmail.com">pieter.wuille@gmail.com</a>> wrote:<br>
>><br>
>> Bitcoin does have parts that rely on economic arguments for securi=
ty or privacy, but can we please stick to using cryptography that is up to =
par for parts where we can? It's a small constant factor of data, and i=
t categorically removes the worry about security levels.<br>
><br>
> Our message may have crossed in the mod queue:<br>
><br>
> "So can we quantify the incremental increase in security of SHA25=
6(SHA256) over RIPEMD160(SHA256) versus the incremental increase in securit=
y of having a simpler implementation of segwitness?"</p>
<p dir=3D"ltr">There are several clever ways to exploit even chosen prefix =
collisions using the scripting language. One could search for collisions wh=
ere one message is some data and the other is a jump over a critical check.=
</p>
<p dir=3D"ltr">><br>
> I believe the history of computer security is that implementation erro=
rs and sidechannel attacks are much, much more common than brute-force brea=
ks. KEEP IT SIMPLE.</p>
<p dir=3D"ltr">Ask the Iranian nuclear program. Or those brainwallet users.=
<br>
><br>
> (and a quibble: =C2=A0"do a 80-bit search for B and C such that H=
(A and B) =3D H(B and C)" =C2=A0isn't enough, you have to end up w=
ith a C public key for which you know the corresponding private key or the =
attacker just succeeds in burning the funds)<br>
><br>
><br>
> -- <br>
> --<br>
> Gavin Andresen<br>
><br>
> _______________________________________________<br>
> bitcoin-dev mailing list<br>
> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@l=
ists.linuxfoundation.org</a><br>
> <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
><br>
</p>
--001a114fe252fdadab0528c87bb3--
|
