Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id DA240721 for ; Wed, 29 Jun 2016 01:38:46 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ob0-f169.google.com (mail-ob0-f169.google.com [209.85.214.169]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BC5BE11A for ; Wed, 29 Jun 2016 01:38:45 +0000 (UTC) Received: by mail-ob0-f169.google.com with SMTP id mu6so5664557obc.3 for ; Tue, 28 Jun 2016 18:38:45 -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=INc2v0X7f/xPT5nBKNgfeBQIZ0nndf6ZF6wBTF+Jn4E=; b=awKlMWccczLWB5e7USBgBHcu3Pa8ew3iHLip7wwIoBOjoWN9tHFWXPIRpDzvah96FA pqzcVGToMBIdpROrFo9W4/MY8OtUcPx7sWm4uQFaF0osVpjNA5kEW1dAM/+I/uJu3pJ+ yFHSfq7yeUmJRGmnUhaKNXJXagBkkExHO8lII/jVD6YmeaFeLLuyxU4UUbIkOHHVMMhc UHB6EkULZXARWDDyyxU44vGBI5rJ+OoRx1Xo+UZGId/EZtC2EpWyfsPUl6N5NOByFkH0 mroLms3IveoyCbOC0k0sZd5YvOi4QyQ6tWVzId9bHPuXrFJ4yqjVV6GRmWCAkGc4FTac NmBw== 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=INc2v0X7f/xPT5nBKNgfeBQIZ0nndf6ZF6wBTF+Jn4E=; b=Wu1MmWXd1IemqSlL30uwnT0fDcVrvRzun3hKjfoEsVY/KUrEFD1ridVMluSW/bDTUe gpzlNGwkJD9YFTXqVbbakCdGSXZzr/374QlpN6E75muVejj5RmPRTWXx+l/eDY7dLRR1 cy2S6/DXLEAX2Yw+jG3QaGWci32FgHPWKd9nhed69mNgDCyfsXHnhr0R5fZfMjnYD841 htvE+sZFeWBi6RqLhzdrwFNTbVsgYoYhKmNPy3uIVuGAmeHFNpE8aYFV/QeBvOFYp+1Q GRbmJCSkFQdSiAUk40qL2IUZ3brayL+W9JkUrzITAqLf29TLjtWoHPDggbTKS2yaUg5f Bf/Q== X-Gm-Message-State: ALyK8tJ47+1rh3scgQQ+oudunml8fSK02EohiLiidUMjCHR27JlSiceyVdw7syqIA+zBfcMB80xoOji2oPoP2TOR X-Received: by 10.202.197.79 with SMTP id v76mr3803425oif.193.1467164324770; Tue, 28 Jun 2016 18:38:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.87.140 with HTTP; Tue, 28 Jun 2016 18:38:44 -0700 (PDT) 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 Date: Wed, 29 Jun 2016 09:38:44 +0800 Message-ID: To: Rusty Russell , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary=001a113e3cd067d93a053660d0e5 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2016 01:38:47 -0000 --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 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
HMAC has proven security property.
It is still secure = even when underlying crypto hashing function has collision resistant weakne= ss.
For example, MD5 is considered completely insecure now, but H= MAC-MD5 is still considered secure.
When in doubt, we should alwa= ys use HMAC for MAC(Message Authentication Code) rather than custom constru= ction

= 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=3Decdh_secret|cipher-type,msg=3D"encrypti= on key").
>>>
>>>=C2=A0 K_1 must be the left 32bytes of the HMAC_SHA512 hash. >>>=C2=A0 K_2 must be the right 32bytes of the HMAC_SHA512 hash. >>
>> This seems a weak reason to introduce SHA512 to the mix.=C2=A0 Can= we just
>> make:
>>
>> K_1 =3D HMAC_SHA256(key=3Decdh_secret|cipher-type,msg=3D"head= er encryption key")
>> K_2 =3D HMAC_SHA256(key=3Decdh_secret|cipher-type,msg=3D"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.=C2=A0 = 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).=C2=A0 But that's probably just my crypto<= br> ignorance...

Thanks!
Rusty.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev



--
=
Xuesong (Arthur) Chen
Senior Principle Engineer
Bloc= kChain Technologist
BTCC
--001a113e3cd067d93a053660d0e5--