MIME-Version: 1.0
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
Subject: Re: [bitcoin-dev] BIP 151 use of HMAC_SHA512
Precedence: list

--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--