📅 Original date posted:2016-06-29
📝 Original message:Just to clarify in BIP-0151 when it says:
>It is important to include the cipher-type into the symmetric cipher key to avoid weak-cipher-attacks.
the cipher-type here refers to the ECDH negotiation parameters?
On Wed, Jun 29, 2016 at 2:58 AM, Pieter Wuille <pieter.wuille at gmail.com> wrote:
> On Jun 29, 2016 07:05, "Ethan Heilman via bitcoin-dev"
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> >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.
>
> This property does technically not apply here, as the output of the hash is
> kept secret, and the possible messages are constants (which are presumably
> chosen in such a way that one is never an extension of another).
>
> However, this is a good example of why you can't generically use a hash
> function in places where you want a MAC (aka "a hash with a shared secret").
> Furthermore, if you already have a hash function anyway, HMAC is very easy
> construct on top of it.
>
> --
> Pieter
Ethan Heilman [ARCHIVE] /
npub1ga…gac47
2023-06-07 17:51:35
in reply to nevent1q…vs2m
Author Public Key
npub1gaszwl7qd0tjmnwcaamgzzgsmzzjlvle6kz0td66pwa8z69vsxsqxgac47Published at
2023-06-07 17:51:35Event JSON
{
"id": "d7046a0bb56681400b0edaeb0e1f89bf04551ed5e1a1b401b8b3571aa88ce2bc",
"pubkey": "4760277fc06bd72dcdd8ef76810910d8852fb3f9d584f5b75a0bba7168ac81a0",
"created_at": 1686160295,
"kind": 1,
"tags": [
[
"e",
"865ae9660ffa796d019b6409907548cf0d8cccc89b3d009b0f6e17232981afa9",
"",
"root"
],
[
"e",
"66017148045ff672155d39064fc418bb8ca7301b328a579ca7666289abaf002b",
"",
"reply"
],
[
"p",
"5cb21bf5d7f25a9d46879713cbd32433bbc10e40ef813a3c28fe7355f49854d6"
]
],
"content": "📅 Original date posted:2016-06-29\n📝 Original message:Just to clarify in BIP-0151 when it says:\n\n\u003eIt is important to include the cipher-type into the symmetric cipher key to avoid weak-cipher-attacks.\n\nthe cipher-type here refers to the ECDH negotiation parameters?\n\nOn Wed, Jun 29, 2016 at 2:58 AM, Pieter Wuille \u003cpieter.wuille at gmail.com\u003e wrote:\n\u003e On Jun 29, 2016 07:05, \"Ethan Heilman via bitcoin-dev\"\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\n\u003e\u003e \u003eIt's also not clear to me why the HMAC, vs just\n\u003e\u003e \u003e SHA256(key|cipher-type|mesg). But that's probably just my crypto\n\u003e\u003e \u003e ignorance...\n\u003e\u003e\n\u003e\u003e SHA256(key|cipher-type|mesg) is an extremely insecure MAC because of\n\u003e\u003e the length extension property of SHA256.\n\u003e\n\u003e This property does technically not apply here, as the output of the hash is\n\u003e kept secret, and the possible messages are constants (which are presumably\n\u003e chosen in such a way that one is never an extension of another).\n\u003e\n\u003e However, this is a good example of why you can't generically use a hash\n\u003e function in places where you want a MAC (aka \"a hash with a shared secret\").\n\u003e Furthermore, if you already have a hash function anyway, HMAC is very easy\n\u003e construct on top of it.\n\u003e\n\u003e --\n\u003e Pieter",
"sig": "380c19ba5e15635fc2fac2ba9f5fa4fbd747db6791ee55321fe1c593c325ffa17bac9a0bddbb20548baac66de9d9b93dc47f454bf508e078e6beb5acf5993f7f"
}