📅 Original date posted:2016-06-28
📝 Original message:> 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.
</jonas>
[1]
https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#child-key-derivation-ckd-functions
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160628/bbe12795/attachment.sig>;
Jonas Schnelli [ARCHIVE] /
npub1nf…3dtxs
2023-06-07 17:51:33
in reply to nevent1q…kkyw
Author Public Key
npub1nfrrurat393mqymf3s26pujyn5vujlem3pzcukr5p9d4qpklngxq43dtxsPublished at
2023-06-07 17:51:33Event JSON
{
"id": "d360b4a802d2636f697f52f574cad006102db8c18d14428bb5d3308c0704a098",
"pubkey": "9a463e0fab8963b013698c15a0f2449d19c97f3b88458e5874095b5006df9a0c",
"created_at": 1686160293,
"kind": 1,
"tags": [
[
"e",
"865ae9660ffa796d019b6409907548cf0d8cccc89b3d009b0f6e17232981afa9",
"",
"root"
],
[
"e",
"afca2128fa22b234ba080710dbfcb08774c52c79b0417a1f48edcba61fa463dd",
"",
"reply"
],
[
"p",
"13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425"
]
],
"content": "📅 Original date posted:2016-06-28\n📝 Original message:\u003e To quote:\n\u003e \n\u003e\u003e HMAC_SHA512(key=ecdh_secret|cipher-type,msg=\"encryption key\").\n\u003e\u003e\n\u003e\u003e K_1 must be the left 32bytes of the HMAC_SHA512 hash.\n\u003e\u003e K_2 must be the right 32bytes of the HMAC_SHA512 hash.\n\u003e \n\u003e This seems a weak reason to introduce SHA512 to the mix. Can we just\n\u003e make:\n\u003e \n\u003e K_1 = HMAC_SHA256(key=ecdh_secret|cipher-type,msg=\"header encryption key\")\n\u003e K_2 = HMAC_SHA256(key=ecdh_secret|cipher-type,msg=\"body encryption key\")\n\nSHA512_HMAC is used by BIP32 [1] and I guess most clients will somehow\nmake use of bip32 features. I though a single SHA512_HMAC operation is\ncheaper and simpler then two SHA256_HMAC.\n\nAFAIK, sha256_hmac is also not used by the current p2p \u0026 consensus layer.\nBitcoin-Core uses it for HTTP RPC auth and Tor control.\n\nI don't see big pros/cons for SHA512_HMAC over SHA256_HMAC.\n\n\u003c/jonas\u003e\n\n[1]\nhttps://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#child-key-derivation-ckd-functions\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 819 bytes\nDesc: OpenPGP digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160628/bbe12795/attachment.sig\u003e",
"sig": "75025270ebf1bcb799ba16fe86521beda22670399d7c96373f181dc5f276f2e12fc1b9d66fc37f1491f75e7a7f770046f16c81be530c69445970a6435c89a9c3"
}