From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 1B6F2958 for ; Tue, 28 Jun 2016 08:31:53 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-oi0-f44.google.com (mail-oi0-f44.google.com [209.85.218.44]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3ABC58E for ; Tue, 28 Jun 2016 08:31:52 +0000 (UTC) Received: by mail-oi0-f44.google.com with SMTP id r2so12890774oih.2 for ; Tue, 28 Jun 2016 01:31:52 -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=uqhCOkAJTCCvGyfNcadYDQN5+mX+cSIIBZEnc9qxFMk=; b=oF3Vc5retWip9q0aaq3Q4tUOuylW6cYwMsZGrMSbJmx99rN8WPHVyB246parew7L22 8E4A6NIsRdjXgTyIQsWD5+MDfRvMAGl6OEkNQ3qj98LiJsnAQWv4i7lDOCdHxOBONMbP FYLC3PnuksJW2YrVmT6476OfReofJtWxHpBVy93s98aWFiUE26JuQfMX19yx8pA5xwoJ b+BMEoBFIOXv6E3ciAYNH3UfA3euO3ZIDs549mXyjaQ/nhSYIoX7OvTqLPPVcWbArAsx tCHRVtXHL8AD09YcoUM7/AjcWqmjwtE3VfxE7VzszWc/t83iUEF0CriH/QRFiR8j3LPg +tVQ== 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=uqhCOkAJTCCvGyfNcadYDQN5+mX+cSIIBZEnc9qxFMk=; b=gtK9fhbIcPs754qJdAjNPjYj8hYr3melfzIyNpcH2XiepYuQg2VZrHcdMeZ7q4PeXl zn/0VoG3CI4yQq/7gKLQNonFeHTgyFTU2VFkeJkDvRWl5zoiyRm9ZcmBr9s1b4gA03d2 8JGlYzvinraspOqjV2AMYcmKC8E76MNvDjKDtnzBH2tVF150mBQP0zgLBW0uypcGTu1Z LIGFi7CrhPs7GUxdgZ2H6qW15wxOtEcfF05+EpNmUSLHFTYPdvy+njfWykXTTHsauqIa SfCxfKWluriMuj359V8ewVrXL9cR875UcOpfLqz8bYTwWZNFnJa8SHKTZ0ZU+wq03gKO kA5Q== X-Gm-Message-State: ALyK8tJOczaPGjrILzBwuYUHfDm7aNknOVVRGgt1zMu3Hau0tZaZGDk8EQhxshYiElvNXXGxCG3SOx+QPXcimais X-Received: by 10.202.79.83 with SMTP id d80mr907565oib.64.1467102711628; Tue, 28 Jun 2016 01:31:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.87.140 with HTTP; Tue, 28 Jun 2016 01:31:51 -0700 (PDT) In-Reply-To: <577224E8.6070307@jonasschnelli.ch> References: <87h9cecad5.fsf@rustcorp.com.au> <577224E8.6070307@jonasschnelli.ch> From: Arthur Chen Date: Tue, 28 Jun 2016 16:31:51 +0800 Message-ID: To: Jonas Schnelli , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary=001a113d7f14f9d4c905365277d8 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 X-Mailman-Approved-At: Tue, 28 Jun 2016 09:29:14 +0000 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: Tue, 28 Jun 2016 08:31:53 -0000 --001a113d7f14f9d4c905365277d8 Content-Type: text/plain; charset=UTF-8 Based on previous crypto analysis result, the actual security of SHA512 is not significantly higher than SHA256. maybe we should consider SHA3? On Tue, Jun 28, 2016 at 3:19 PM, Jonas Schnelli via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > 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. > > AFAIK, sha256_hmac is also not used by the current p2p & consensus layer. > Bitcoin-Core uses it for HTTP RPC auth and Tor control. > > I don't see big pros/cons for SHA512_HMAC over SHA256_HMAC. > > > > [1] > > https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#child-key-derivation-ckd-functions > > > _______________________________________________ > 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 --001a113d7f14f9d4c905365277d8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Based on previous crypto analysis result, the actual secur= ity of SHA512 is not significantly higher than SHA256.
maybe we should = consider SHA3?

On Tue, Jun 28, 2016 at 3:19 PM, Jonas Schnelli= via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.or= g> wrote:
= > To quote:
>
>> HMAC_SHA512(key=3Decdh_secret|cipher-type,msg=3D"encryption k= ey").
>>
>>=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"header e= ncryption key")
> K_2 =3D HMAC_SHA256(key=3Decdh_secret|cipher-type,msg=3D"body enc= ryption key")

SHA512_HMAC is used by BIP32 [1] and I guess most clients will someh= ow
make use of bip32 features. I though a single SHA512_HMAC operation is
cheaper and simpler then two SHA256_HMAC.

AFAIK, sha256_hmac is also not used by the current p2p & consensus laye= r.
Bitcoin-Core uses it for HTTP RPC auth and Tor control.

I don't see big pros/cons for SHA512_HMAC over SHA256_HMAC.

</jonas>

[1]
htt= ps://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#child-key-deriv= ation-ckd-functions


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




--
= Xuesong (Arthur) Chen
Senior Principle Engineer
BlockChain Te= chnologist
BTCC
--001a113d7f14f9d4c905365277d8--