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
|
Return-Path: <jtimon@jtimon.cc>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 70919A3F
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 11 Jan 2016 20:32:17 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vk0-f53.google.com (mail-vk0-f53.google.com
[209.85.213.53])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D8FEF11D
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 11 Jan 2016 20:32:16 +0000 (UTC)
Received: by mail-vk0-f53.google.com with SMTP id a123so200508257vkh.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 11 Jan 2016 12:32:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=jtimon-cc.20150623.gappssmtp.com; s=20150623;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=KwGz82R+5VulomWKHvYmZthYgbPlh+H7hwG1ktvkbBY=;
b=p1pFmg23dwHnCHhGLc20gj1pLxw1hw3Eg2TblkSV6+GEzEdbIV1f4Z2rRQaRdDkwZM
yW2bLAyrQZ7sLgk1S/uGs+UAB03IjQ9JWXv1GhiWB/qcRalYe6xrExgWHe9cxtb3morM
S5VMHNgsegjG1Yf+57I9xaPjil5UL/rITm6VZXVoZpkDvJpsBL/26XCzbuEP3uGm8Js9
6U5K81qcy/qVeZd2l/ZoE2KfbWKNhFiyrmeVLpFvUWGoQK1WhVCefmn+FFnZbL13M2Ao
Ew5oP/+MEmIZJvWgFWeOGQReIMiPHfRauTljmHwSwzi2KhVSuCn2y8nLqmzcjgp7HZ1k
v7aA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type;
bh=KwGz82R+5VulomWKHvYmZthYgbPlh+H7hwG1ktvkbBY=;
b=ghc/YzJZCdoyb0NLs8VHEWICusKIPsvsW0Bq9N74/qF6vNvc7RnI5F7oc24FIBqlcH
tFZYb2x6G+ruVDQobt2NTbZx1xoUW/dRpHNFisW7xFCfBCftljF/NgTd4Kkeiudyd+Ja
bfM/QoazRnCyWLfVyijY9VTvqskyMwNzLc85HXED0LhFxe7llhF5s6+s8w9NyRhuSHcG
cVvWNyKaMa88Ugzx/kvelvJq3UCqISOIIhd7et5SA1fKXsIf16gPds6IUYE/dMgN0ixJ
Nim72eID0o00jHzynoRHgk7n61nLNZsQf+B4FbnCtC4VaJ5yUo5L/i3wEBYn7Z8bkN64
bR1g==
X-Gm-Message-State: ALoCoQlHp13gztQWxCKbGOlurGualfB4btpLga62Gj6JwaIy5OrI/AWzG9R2lCtKv61ZlcvOvETI5A54j+i5Q6YVvA+UtpN0dQ==
MIME-Version: 1.0
X-Received: by 10.31.154.213 with SMTP id c204mr91035348vke.38.1452544335926;
Mon, 11 Jan 2016 12:32:15 -0800 (PST)
Received: by 10.31.141.73 with HTTP; Mon, 11 Jan 2016 12:32:15 -0800 (PST)
In-Reply-To: <CABsx9T0WRXz54LZnyU7Fr=_ZgwF5armj0Z8uwYcFy2x+BWooxg@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>
<CABsx9T0WRXz54LZnyU7Fr=_ZgwF5armj0Z8uwYcFy2x+BWooxg@mail.gmail.com>
Date: Mon, 11 Jan 2016 21:32:15 +0100
Message-ID: <CABm2gDrQx-ETyCk1XOCGKwsLeTQU_gPG_Gpjx=bbf2qHpE1u=w@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: text/plain; charset=UTF-8
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,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
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: Mon, 11 Jan 2016 20:32:17 -0000
On Fri, Jan 8, 2016 at 4:50 PM, Gavin Andresen via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> And to fend off the messag that I bet somebody is composing right now:
>
> Yes, I know about a "security first" mindset. But as I said earlier in the
> thread, there is a tradeoff here between crypto strength and code
> complexity, and "the strength of the crypto is all that matters" is NOT
> security first.
If the crypto code is properly encapsulated, the code complexity costs
of choosing one hashing function over another should be non-existent.
You made the space argument which is valid, but in my opinion code
complexity shouldn't be a valid concern in this discussion.
As a maybe uninteresting anecdote, I proposed the asset IDs in
https://github.com/ElementsProject/elements/tree/alpha-0.10-multi-asset
to do the same ```ripemd160 . sha256``` choice that Mark Friedenbach
had proposed and I had approved for
https://github.com/jtimon/freimarkets/blob/master/doc/freimarkets_specs.org#asset-tags
. More humble than me, he admitted he had made a design mistake much
earlier than me, who (maybe paradoxically) probably had less knowledge
for making crypto choices at the low level. In the end I was convinced
with examples I failed to write down for documentation and can't
remember.
That's not to say I have anything to say in this debate other than
code complexity (which I do feel qualified to talk about) shouldn't be
a concern in this debate. Just want to focus the discussion on what it
should be: security vs space tradeoff.
Since I am admittedly in doubt, I tend to prefer to play safe, but
neither my feelings nor my anecdote are logical arguments and should,
therefore, be ignored for any conclusions in the ```ripemd160 .
sha256``` vs sha256d debate. Just like you non-sequitor "sha256d will
lead to more code complexity", if anything, sha256d should be simpler
than ```ripemd160 . sha256``` (but not simpler enough that it matters
much).
|
