MIME-Version: 1.0
In-Reply-To: <8760ssdd1u.fsf@rustcorp.com.au>
References: <87h9cecad5.fsf@rustcorp.com.au>
	<577224E8.6070307@jonasschnelli.ch>
	<8760ssdd1u.fsf@rustcorp.com.au>
From: Arthur Chen <arthur.chen@btcc.com>
Date: Wed, 29 Jun 2016 09:38:44 +0800
Message-ID: <CAP+0UNJ0hVK3FxST0PzaqDx+T7A0rOtCpcnZRPt+8Bn4TmUHNw@mail.gmail.com>
To: Rusty Russell <rusty@rustcorp.com.au>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a113e3cd067d93a053660d0e5
Subject: Re: [bitcoin-dev] BIP 151 use of HMAC_SHA512
Precedence: list

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

HMAC has proven security property.
It is still secure even when underlying crypto hashing function has
collision resistant weakness.
For example, MD5 is considered completely insecure now, but HMAC-MD5 is
still considered secure.
When in doubt, we should always use HMAC for MAC(Message Authentication
Code) rather than custom construction

On Wed, Jun 29, 2016 at 9:00 AM, Rusty Russell via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Jonas Schnelli <dev@jonasschnelli.ch> writes:
> >> To quote:
> >>
> >>> HMAC_SHA512(key=ecdh_secret|cipher-type,msg="encryption key").
> >>>
> >>>  K_1 must be the left 32bytes of the HMAC_SHA512 hash.
> >>>  K_2 must be the right 32bytes of the HMAC_SHA512 hash.
> >>
> >> This seems a weak reason to introduce SHA512 to the mix.  Can we just
> >> make:
> >>
> >> K_1 = HMAC_SHA256(key=ecdh_secret|cipher-type,msg="header encryption
> key")
> >> K_2 = HMAC_SHA256(key=ecdh_secret|cipher-type,msg="body encryption key")
> >
> > SHA512_HMAC is used by BIP32 [1] and I guess most clients will somehow
> > make use of bip32 features. I though a single SHA512_HMAC operation is
> > cheaper and simpler then two SHA256_HMAC.
>
> Good point; I would argue that mistake has already been made.  But I was
> looking at appropriating your work for lightning inter-node comms, and
> adding another hash algo seemed unnecessarily painful.
>
> > AFAIK, sha256_hmac is also not used by the current p2p & consensus layer.
> > Bitcoin-Core uses it for HTTP RPC auth and Tor control.
>
> It's also not clear to me why the HMAC, vs just
> SHA256(key|cipher-type|mesg).  But that's probably just my crypto
> ignorance...
>
> Thanks!
> Rusty.
> _______________________________________________
> 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

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

<div dir=3D"ltr">HMAC has proven security property.<div>It is still secure =
even when underlying crypto hashing function has collision resistant weakne=
ss.</div><div>For example, MD5 is considered completely insecure now, but H=
MAC-MD5 is still considered secure.</div><div>When in doubt, we should alwa=
ys use HMAC for MAC(Message Authentication Code) rather than custom constru=
ction</div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Wed, Jun 29, 2016 at 9:00 AM, Rusty Russell via bitcoin-dev <span dir=3D=
"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=
=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-left:1p=
x #ccc solid;padding-left:1ex"><span class=3D"">Jonas Schnelli &lt;<a href=
=3D"mailto:dev@jonasschnelli.ch">dev@jonasschnelli.ch</a>&gt; writes:<br>
&gt;&gt; To quote:<br>
&gt;&gt;<br>
&gt;&gt;&gt; HMAC_SHA512(key=3Decdh_secret|cipher-type,msg=3D&quot;encrypti=
on key&quot;).<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;=C2=A0 K_1 must be the left 32bytes of the HMAC_SHA512 hash.<br=
>
&gt;&gt;&gt;=C2=A0 K_2 must be the right 32bytes of the HMAC_SHA512 hash.<b=
r>
&gt;&gt;<br>
&gt;&gt; This seems a weak reason to introduce SHA512 to the mix.=C2=A0 Can=
 we just<br>
&gt;&gt; make:<br>
&gt;&gt;<br>
&gt;&gt; K_1 =3D HMAC_SHA256(key=3Decdh_secret|cipher-type,msg=3D&quot;head=
er encryption key&quot;)<br>
&gt;&gt; K_2 =3D HMAC_SHA256(key=3Decdh_secret|cipher-type,msg=3D&quot;body=
 encryption key&quot;)<br>
&gt;<br>
&gt; SHA512_HMAC is used by BIP32 [1] and I guess most clients will somehow=
<br>
&gt; make use of bip32 features. I though a single SHA512_HMAC operation is=
<br>
&gt; cheaper and simpler then two SHA256_HMAC.<br>
<br>
</span>Good point; I would argue that mistake has already been made.=C2=A0 =
But I was<br>
looking at appropriating your work for lightning inter-node comms, and<br>
adding another hash algo seemed unnecessarily painful.<br>
<span class=3D""><br>
&gt; AFAIK, sha256_hmac is also not used by the current p2p &amp; consensus=
 layer.<br>
&gt; Bitcoin-Core uses it for HTTP RPC auth and Tor control.<br>
<br>
</span>It&#39;s also not clear to me why the HMAC, vs just<br>
SHA256(key|cipher-type|mesg).=C2=A0 But that&#39;s probably just my crypto<=
br>
ignorance...<br>
<br>
Thanks!<br>
<div class=3D"HOEnZb"><div class=3D"h5">Rusty.<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">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"><div><br></div>-- <br>=
<div class=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div dir=
=3D"ltr">Xuesong (Arthur) Chen<div>Senior Principle Engineer</div><div>Bloc=
kChain Technologist</div><div>BTCC</div></div></div>
</div>

--001a113e3cd067d93a053660d0e5--