MIME-Version: 1.0
In-Reply-To: <87oa6iavky.fsf@rustcorp.com.au>
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>
From: Zooko Wilcox <zooko@z.cash>
Date: Fri, 1 Jul 2016 22:42:19 +0000
Message-ID: <CADorodhC=UvQmiNVSd91dA57PyYydDH+uUUp_Aj5CsN-EG-e4g@mail.gmail.com>
To: Rusty Russell <rusty@rustcorp.com.au>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [bitcoin-dev] BIP 151 use of HMAC_SHA512
Precedence: list

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