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