1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
|
Return-Path: <arthur.chen@btcc.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id DA240721
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 29 Jun 2016 01:38:45 +0000 (UTC)
Received: by mail-ob0-f169.google.com with SMTP id mu6so5664557obc.3
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <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
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <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"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=
=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>></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 <<a href=
=3D"mailto:dev@jonasschnelli.ch">dev@jonasschnelli.ch</a>> writes:<br>
>> To quote:<br>
>><br>
>>> HMAC_SHA512(key=3Decdh_secret|cipher-type,msg=3D"encrypti=
on key").<br>
>>><br>
>>>=C2=A0 K_1 must be the left 32bytes of the HMAC_SHA512 hash.<br=
>
>>>=C2=A0 K_2 must be the right 32bytes of the HMAC_SHA512 hash.<b=
r>
>><br>
>> This seems a weak reason to introduce SHA512 to the mix.=C2=A0 Can=
we just<br>
>> make:<br>
>><br>
>> K_1 =3D HMAC_SHA256(key=3Decdh_secret|cipher-type,msg=3D"head=
er encryption key")<br>
>> K_2 =3D HMAC_SHA256(key=3Decdh_secret|cipher-type,msg=3D"body=
encryption key")<br>
><br>
> SHA512_HMAC is used by BIP32 [1] and I guess most clients will somehow=
<br>
> make use of bip32 features. I though a single SHA512_HMAC operation is=
<br>
> 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>
> AFAIK, sha256_hmac is also not used by the current p2p & consensus=
layer.<br>
> Bitcoin-Core uses it for HTTP RPC auth and Tor control.<br>
<br>
</span>It's also not clear to me why the HMAC, vs just<br>
SHA256(key|cipher-type|mesg).=C2=A0 But that'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--
|
