📅 Original date posted:2016-06-28 📝 Original message:>It's also not clear to me ...

Ethan Heilman [ARCHIVE] /

npub1gas…ac47

2023-06-07 17:51:34

in reply to nevent1q…6gl7

📅 Original date posted:2016-06-28
📝 Original message:>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...

SHA256(key|cipher-type|mesg) is an extremely insecure MAC because of
the length extension property of SHA256.

If I have a tag y = SHA256(key|cipher-type|mesg), I can without
knowing key or msg compute a value y' such that
y' = SHA256(key|cipher-type|mesg|any values I want).

Thus, an attacker can trivially forge a tag protected by
SHA256(key|cipher-type|mesg).

For more details see:
https://web.archive.org/web/20141029080820/http://vudang.com/2012/03/md5-length-extension-attack/

On Tue, Jun 28, 2016 at 9:00 PM, Rusty Russell via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> 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.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Author Public Key

npub1gaszwl7qd0tjmnwcaamgzzgsmzzjlvle6kz0td66pwa8z69vsxsqxgac47

Seen on

wss://relay.nostr.band

Show more details

Published at

2023-06-07 17:51:34

Kind type

1 Short Text Note

Event JSON

{ "id": "f8d908387b39c4b5bde130a42fdbe9a435ef31b43624e8faff15a4aaa263beba", "pubkey": "4760277fc06bd72dcdd8ef76810910d8852fb3f9d584f5b75a0bba7168ac81a0", "created_at": 1686160294, "kind": 1, "tags": [ [ "e", "865ae9660ffa796d019b6409907548cf0d8cccc89b3d009b0f6e17232981afa9", "", "root" ], [ "e", "ee65540c3efe1d33976de20d78014a7205c1febd010533e5a01d2607c46b9c99", "", "reply" ], [ "p", "0ec696b29b886ff506f97f10972898662046456c04d742188879d8f95cafd423" ] ], "content": "📅 Original date posted:2016-06-28\n📝 Original message:\u003eIt's also not clear to me why the HMAC, vs just SHA256(key|cipher-type|mesg). But that's probably just my crypto ignorance...\n\nSHA256(key|cipher-type|mesg) is an extremely insecure MAC because of\nthe length extension property of SHA256.\n\nIf I have a tag y = SHA256(key|cipher-type|mesg), I can without\nknowing key or msg compute a value y' such that\ny' = SHA256(key|cipher-type|mesg|any values I want).\n\nThus, an attacker can trivially forge a tag protected by\nSHA256(key|cipher-type|mesg).\n\nFor more details see:\nhttps://web.archive.org/web/20141029080820/http://vudang.com/2012/03/md5-length-extension-attack/\n\nOn Tue, Jun 28, 2016 at 9:00 PM, Rusty Russell via bitcoin-dev\n\u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e Jonas Schnelli \u003cdev at jonasschnelli.ch\u003e writes:\n\u003e\u003e\u003e To quote:\n\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e HMAC_SHA512(key=ecdh_secret|cipher-type,msg=\"encryption key\").\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e K_1 must be the left 32bytes of the HMAC_SHA512 hash.\n\u003e\u003e\u003e\u003e K_2 must be the right 32bytes of the HMAC_SHA512 hash.\n\u003e\u003e\u003e\n\u003e\u003e\u003e This seems a weak reason to introduce SHA512 to the mix. Can we just\n\u003e\u003e\u003e make:\n\u003e\u003e\u003e\n\u003e\u003e\u003e K_1 = HMAC_SHA256(key=ecdh_secret|cipher-type,msg=\"header encryption key\")\n\u003e\u003e\u003e K_2 = HMAC_SHA256(key=ecdh_secret|cipher-type,msg=\"body encryption key\")\n\u003e\u003e\n\u003e\u003e SHA512_HMAC is used by BIP32 [1] and I guess most clients will somehow\n\u003e\u003e make use of bip32 features. I though a single SHA512_HMAC operation is\n\u003e\u003e cheaper and simpler then two SHA256_HMAC.\n\u003e\n\u003e Good point; I would argue that mistake has already been made. But I was\n\u003e looking at appropriating your work for lightning inter-node comms, and\n\u003e adding another hash algo seemed unnecessarily painful.\n\u003e\n\u003e\u003e AFAIK, sha256_hmac is also not used by the current p2p \u0026 consensus layer.\n\u003e\u003e Bitcoin-Core uses it for HTTP RPC auth and Tor control.\n\u003e\n\u003e It's also not clear to me why the HMAC, vs just\n\u003e SHA256(key|cipher-type|mesg). But that's probably just my crypto\n\u003e ignorance...\n\u003e\n\u003e Thanks!\n\u003e Rusty.\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev", "sig": "4bced35b542441f46eaeba4cf8cfbf77040f4d9365f67e63aa1b901bdc63c6b293ccbde946ddb18ce08e0029161e5d603805fec3da32f5cdd2c6765069725129" }