summaryrefslogtreecommitdiff
path: root/f3/776f278df3735699769726b90833cecba9f1f8
blob: 7951b2c73dc7256ed0195ffe33247ce0a74481bd (plain)
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
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
Return-Path: <arthur.chen@btcc.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 183D71BB
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon,  4 Jul 2016 01:44:36 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-oi0-f68.google.com (mail-oi0-f68.google.com
	[209.85.218.68])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 959FC1BC
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon,  4 Jul 2016 01:44:31 +0000 (UTC)
Received: by mail-oi0-f68.google.com with SMTP id w141so21175260oia.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 03 Jul 2016 18:44:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=btcc-com.20150623.gappssmtp.com; s=20150623;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc; bh=ddRJWKcYD3BPW291orsCyiY8gVOBzQ8un9pOmAkaTpg=;
	b=KNOqvI8DVmyGXppPGXkLdzByZ0P98kyPJPcIfSic8SeLshAQSPI//Cp1lIwEGBEbzT
	jhKLwyY2kChLbF0k4QZ7A9MfO76PNxJoI2yj27VC4UMXektqG6HGahpwPaHeVBN0fV6C
	oELsYRWi+kgKMOO0tK5FhaWVsCuXmneoFuV8TYtHPSxC0u4rGvoKMTsD5jOvgPt3HpVt
	tv4y2LGvOKKhELh0TFkxHe/yurO779PeZEENX6FSNcD2p/DwK1wrzSPunxH/uHtSAlFU
	tzkMjQyKWhIEgwDbZFVdeBElwdMgFw5onyjRQsmiIuKtqjcq/GxRZp+a/m8RWDzGLpls
	cmgQ==
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:from:date
	:message-id:subject:to:cc;
	bh=ddRJWKcYD3BPW291orsCyiY8gVOBzQ8un9pOmAkaTpg=;
	b=AEQYt+wjcW2z5q4wWb2a1wMI9qXzJdEhOL5dObOIp44Zzg/ob8Xin/V0V96PZtfPk6
	I4jjKxcjqcgYdbuyEiIDXBoWMT+Zytf4iQyjnaP5D/rWNwZ9GeX9iRcjKqS8kBDtZ/1s
	PWQd3PjrEuHPxPaGsml6skB1mUCTvq2NNYsdautT0EI26gNPsm1NDFJ3WHAzmFCsmPZh
	DrDrRitBu0f9iur753xhpHNR8eeEqwM71c/iGPIpY0bu0qkjEMvOjzRcPxmvQqkbG47Z
	OtprQ3B7YjTS0PKa6aqflwRrxYcdqLhTlZykK47WL5ad1YVzcJBoUU5ANolJhhi4CsI0
	HiSQ==
X-Gm-Message-State: ALyK8tLen9eO4am7Qv/8M6e35Su5mpmuA2uzYLJF5pqSOnjAKWAVmFq/z/3OW4I3awJrOfBYJLS3B1Bz0nmEBEVJ
X-Received: by 10.202.194.85 with SMTP id s82mr5558532oif.102.1467596670728;
	Sun, 03 Jul 2016 18:44:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.202.87.140 with HTTP; Sun, 3 Jul 2016 18:44:30 -0700 (PDT)
In-Reply-To: <CAP+0UNJ9mBCWCNf_kSo+4xJWjmO=eVmrrRi7=dD9_zmU2h3cDw@mail.gmail.com>
References: <87h9cecad5.fsf@rustcorp.com.au>
	<577224E8.6070307@jonasschnelli.ch>
	<8760ssdd1u.fsf@rustcorp.com.au>
	<CAEM=y+XKQZVz6UieB-nDy_C9xTmXiBB3-atuuZkxzmPoSVPOJw@mail.gmail.com>
	<87oa6iavky.fsf@rustcorp.com.au>
	<CADorodhC=UvQmiNVSd91dA57PyYydDH+uUUp_Aj5CsN-EG-e4g@mail.gmail.com>
	<CAP+0UNJ9mBCWCNf_kSo+4xJWjmO=eVmrrRi7=dD9_zmU2h3cDw@mail.gmail.com>
From: Arthur Chen <arthur.chen@btcc.com>
Date: Mon, 4 Jul 2016 01:44:30 +0000
Message-ID: <CAP+0UNJ77tdC+HK=x4CtYuTECoqzcMMOd8B38O1hnD5gwoNC5Q@mail.gmail.com>
To: Zooko Wilcox <zooko@z.cash>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a113db0983b9a820536c57a8b
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,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
Subject: Re: [bitcoin-dev] BIP 151 use of HMAC_SHA512
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: Mon, 04 Jul 2016 01:44:36 -0000

--001a113db0983b9a820536c57a8b
Content-Type: text/plain; charset=UTF-8

https://www.schneier.com/crypto-gram/archives/1998/1015.html#cipherdesign

On Mon, Jul 4, 2016 at 1:23 AM, Arthur Chen <arthur.chen@btcc.com> wrote:

> I strongly agree!
> In crypto we should always follow well-studied open standard rather than
> custom construction.
>
> On Fri, Jul 1, 2016 at 10:42 PM, Zooko Wilcox via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> I haven't been able to find the beginning of this thread, so apologies
>> if I've misunderstood what this is for, but it _sounds_ like we're
>> re-inventing HKDF.
>>
>> I'd recommend reading the paper about HKDF. It stands out among crypto
>> papers for having a nice clear justification for each of its design
>> decisions, so you can see why they did it (very slightly) differently
>> than the various constructions proposed up-thread.
>>
>> https://eprint.iacr.org/2010/264
>>
>> Also, of course, it is a great idea to re-use a standard
>> (https://tools.ietf.org/html/rfc5869) and widely-understood crypto
>> algorithm to reduce risk of both cryptographer errors and implementor
>> errors.
>>
>> Of course, the cost of that is the you sometimes end up computing
>> something that is a tiny bit more complicated or inefficient than a
>> custom algorithm for our current use case. IMHO that's a cheap price
>> to pay.
>>
>> Regards,
>>
>> Zooko
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
>
> --
> Xuesong (Arthur) Chen
> Senior Principle Engineer
> BlockChain Technologist
> BTCC
>



-- 
Xuesong (Arthur) Chen
Senior Principle Engineer
BlockChain Technologist
BTCC

--001a113db0983b9a820536c57a8b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><a href=3D"https://www.schneier.com/crypto-gram/archives/1=
998/1015.html#cipherdesign">https://www.schneier.com/crypto-gram/archives/1=
998/1015.html#cipherdesign</a><br></div><div class=3D"gmail_extra"><br><div=
 class=3D"gmail_quote">On Mon, Jul 4, 2016 at 1:23 AM, Arthur Chen <span di=
r=3D"ltr">&lt;<a href=3D"mailto:arthur.chen@btcc.com" target=3D"_blank">art=
hur.chen@btcc.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><=
div dir=3D"ltr"><div>I strongly agree!<br></div>In crypto we should always =
follow well-studied open standard rather than custom construction.<br></div=
><div class=3D"gmail_extra"><div><div class=3D"h5"><br><div class=3D"gmail_=
quote">On Fri, Jul 1, 2016 at 10:42 PM, Zooko Wilcox via bitcoin-dev <span =
dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" ta=
rget=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:=
<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex">I haven&#39;t been able to find the begi=
nning of this thread, so apologies<br>
if I&#39;ve misunderstood what this is for, but it _sounds_ like we&#39;re<=
br>
re-inventing HKDF.<br>
<br>
I&#39;d recommend reading the paper about HKDF. It stands out among crypto<=
br>
papers for having a nice clear justification for each of its design<br>
decisions, so you can see why they did it (very slightly) differently<br>
than the various constructions proposed up-thread.<br>
<br>
<a href=3D"https://eprint.iacr.org/2010/264" rel=3D"noreferrer" target=3D"_=
blank">https://eprint.iacr.org/2010/264</a><br>
<br>
Also, of course, it is a great idea to re-use a standard<br>
(<a href=3D"https://tools.ietf.org/html/rfc5869" rel=3D"noreferrer" target=
=3D"_blank">https://tools.ietf.org/html/rfc5869</a>) and widely-understood =
crypto<br>
algorithm to reduce risk of both cryptographer errors and implementor<br>
errors.<br>
<br>
Of course, the cost of that is the you sometimes end up computing<br>
something that is a tiny bit more complicated or inefficient than a<br>
custom algorithm for our current use case. IMHO that&#39;s a cheap price<br=
>
to pay.<br>
<br>
Regards,<br>
<br>
Zooko<br>
<div><div>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</div></div></blockquote></div><br><br clear=3D"all"><br></div></div><span =
class=3D"">-- <br><div data-smartmail=3D"gmail_signature"><div dir=3D"ltr">=
Xuesong (Arthur) Chen<div>Senior Principle Engineer</div><div>BlockChain Te=
chnologist</div><div>BTCC</div></div></div>
</span></div>
</blockquote></div><br><br clear=3D"all"><br>-- <br><div class=3D"gmail_sig=
nature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr">Xuesong (Arthur=
) Chen<div>Senior Principle Engineer</div><div>BlockChain Technologist</div=
><div>BTCC</div></div></div>
</div>

--001a113db0983b9a820536c57a8b--