📅 Original date posted:2016-06-28
📝 Original message:Jonas Schnelli <dev at 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.
Rusty Russell [ARCHIVE] /
npub1zw…hkhpx
2023-06-07 17:51:34
in reply to nevent1q…wen8
Author Public Key
npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxPublished at
2023-06-07 17:51:34Event JSON
{
"id": "a4080b93dfc782cf5cab8ef59c140a0db2df3bc1a61d2948087d0c90dbaa398b",
"pubkey": "13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425",
"created_at": 1686160294,
"kind": 1,
"tags": [
[
"e",
"865ae9660ffa796d019b6409907548cf0d8cccc89b3d009b0f6e17232981afa9",
"",
"root"
],
[
"e",
"0ba12c4ab3211ffcc3c048be6df3f705385aa22e49a61667bef4a54c3522959a",
"",
"reply"
],
[
"p",
"9a463e0fab8963b013698c15a0f2449d19c97f3b88458e5874095b5006df9a0c"
]
],
"content": "📅 Original date posted:2016-06-28\n📝 Original message:Jonas Schnelli \u003cdev at jonasschnelli.ch\u003e writes:\n\u003e\u003e To quote:\n\u003e\u003e \n\u003e\u003e\u003e HMAC_SHA512(key=ecdh_secret|cipher-type,msg=\"encryption key\").\n\u003e\u003e\u003e\n\u003e\u003e\u003e K_1 must be the left 32bytes of the HMAC_SHA512 hash.\n\u003e\u003e\u003e K_2 must be the right 32bytes of the HMAC_SHA512 hash.\n\u003e\u003e \n\u003e\u003e This seems a weak reason to introduce SHA512 to the mix. Can we just\n\u003e\u003e make:\n\u003e\u003e \n\u003e\u003e K_1 = HMAC_SHA256(key=ecdh_secret|cipher-type,msg=\"header encryption key\")\n\u003e\u003e K_2 = HMAC_SHA256(key=ecdh_secret|cipher-type,msg=\"body encryption key\")\n\u003e\n\u003e SHA512_HMAC is used by BIP32 [1] and I guess most clients will somehow\n\u003e make use of bip32 features. I though a single SHA512_HMAC operation is\n\u003e cheaper and simpler then two SHA256_HMAC.\n\nGood point; I would argue that mistake has already been made. But I was\nlooking at appropriating your work for lightning inter-node comms, and\nadding another hash algo seemed unnecessarily painful.\n\n\u003e AFAIK, sha256_hmac is also not used by the current p2p \u0026 consensus layer.\n\u003e Bitcoin-Core uses it for HTTP RPC auth and Tor control.\n\nIt's also not clear to me why the HMAC, vs just\nSHA256(key|cipher-type|mesg). But that's probably just my crypto\nignorance...\n\nThanks!\nRusty.",
"sig": "c47bc888ec4ca561324326cede1ec74a950fe7c9ffe9cae4e217acd03f2079d6b970d7b339ecbaabf806e1de86b1a4a7fc3ac1361a4c5d57caf9e1377cc207ef"
}