Re: [bitcoin-dev] BIP 151 use of HMAC_SHA512
Hi Arthur > > I strongly agree! > In crypto we should always follow well-studied open standard rather > than custom construction. I totally agree. BIP151 does not introduce new cipher types. The BIP uses ECDH together with ChaCha20-Poly1305@openssh. Both very well known and broad used crypo. /jonas signature.asc Description: OpenPGP digital signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP 151 use of HMAC_SHA512
> I haven't been able to find the beginning of this thread, so apologies > if I've misunderstood what this is for, but it _sounds_ like we're > re-inventing HKDF. > I'd recommend reading the paper about HKDF. It stands out among crypto > papers for having a nice clear justification for each of its design > decisions, so you can see why they did it (very slightly) differently > than the various constructions proposed up-thread. Thanks Zooko I think HKDF instead of a single HMAC_SHA512 seams reasonable and something we should consider. I'll try to evaluate the implications of using HKDF over HMAC_SHA512 and will update the BIP if there are no concerns about it. signature.asc Description: OpenPGP digital signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP 151 use of HMAC_SHA512
https://www.schneier.com/crypto-gram/archives/1998/1015.html#cipherdesign On Mon, Jul 4, 2016 at 1:23 AM, Arthur Chen wrote: > I strongly agree! > In crypto we should always follow well-studied open standard rather than > custom construction. > > On Fri, Jul 1, 2016 at 10:42 PM, Zooko Wilcox via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> I haven't been able to find the beginning of this thread, so apologies >> if I've misunderstood what this is for, but it _sounds_ like we're >> re-inventing HKDF. >> >> I'd recommend reading the paper about HKDF. It stands out among crypto >> papers for having a nice clear justification for each of its design >> decisions, so you can see why they did it (very slightly) differently >> than the various constructions proposed up-thread. >> >> https://eprint.iacr.org/2010/264 >> >> Also, of course, it is a great idea to re-use a standard >> (https://tools.ietf.org/html/rfc5869) and widely-understood crypto >> algorithm to reduce risk of both cryptographer errors and implementor >> errors. >> >> Of course, the cost of that is the you sometimes end up computing >> something that is a tiny bit more complicated or inefficient than a >> custom algorithm for our current use case. IMHO that's a cheap price >> to pay. >> >> Regards, >> >> Zooko >> ___ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > > > > -- > Xuesong (Arthur) Chen > Senior Principle Engineer > BlockChain Technologist > BTCC > -- Xuesong (Arthur) Chen Senior Principle Engineer BlockChain Technologist BTCC ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP 151 use of HMAC_SHA512
I strongly agree! In crypto we should always follow well-studied open standard rather than custom construction. On Fri, Jul 1, 2016 at 10:42 PM, Zooko Wilcox via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > I haven't been able to find the beginning of this thread, so apologies > if I've misunderstood what this is for, but it _sounds_ like we're > re-inventing HKDF. > > I'd recommend reading the paper about HKDF. It stands out among crypto > papers for having a nice clear justification for each of its design > decisions, so you can see why they did it (very slightly) differently > than the various constructions proposed up-thread. > > https://eprint.iacr.org/2010/264 > > Also, of course, it is a great idea to re-use a standard > (https://tools.ietf.org/html/rfc5869) and widely-understood crypto > algorithm to reduce risk of both cryptographer errors and implementor > errors. > > Of course, the cost of that is the you sometimes end up computing > something that is a tiny bit more complicated or inefficient than a > custom algorithm for our current use case. IMHO that's a cheap price > to pay. > > Regards, > > Zooko > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > -- Xuesong (Arthur) Chen Senior Principle Engineer BlockChain Technologist BTCC ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP 151 use of HMAC_SHA512
I haven't been able to find the beginning of this thread, so apologies if I've misunderstood what this is for, but it _sounds_ like we're re-inventing HKDF. I'd recommend reading the paper about HKDF. It stands out among crypto papers for having a nice clear justification for each of its design decisions, so you can see why they did it (very slightly) differently than the various constructions proposed up-thread. https://eprint.iacr.org/2010/264 Also, of course, it is a great idea to re-use a standard (https://tools.ietf.org/html/rfc5869) and widely-understood crypto algorithm to reduce risk of both cryptographer errors and implementor errors. Of course, the cost of that is the you sometimes end up computing something that is a tiny bit more complicated or inefficient than a custom algorithm for our current use case. IMHO that's a cheap price to pay. Regards, Zooko ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP 151 use of HMAC_SHA512
Ethan Heilman writes: >>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). Not quite, there's an important subtlety that SHA256 appends the bitlength, so you can only create: y' = SHA256(key|cipher-type|mesg|padding|bitlength|any values I want). But we're not using this for a MAC in BIP151, we're using this to generate the encryption keys. Arthur Chen said: > HMAC has proven security property. > It is still secure even when underlying crypto hashing function has > collision resistant weakness. > For example, MD5 is considered completely insecure now, but HMAC-MD5 is > still considered secure. > When in doubt, we should always use HMAC for MAC(Message Authentication > Code) rather than custom construction Bitcoin already relies on SHA256's robustness, but again, we don't need a MAC here. I'm happy to buy "we just copied ssh" if that's the answer, and I can't see anything wrong with using HMAC here, it just seems odd... Thanks! Rusty. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP 151 use of HMAC_SHA512
> On Wed, Jun 29, 2016 at 08:34:06PM +0200, Jonas Schnelli via bitcoin-dev > wrote: >>> Based on previous crypto analysis result, the actual security of SHA512 >>> is not significantly higher than SHA256. >>> maybe we should consider SHA3? >> >> As far as I know the security of the symmetric cipher key mainly depends >> on the PRNG and the ECDH scheme. >> >> The HMAC_SHA512 will be used to "drive" keys from the ECDH shared secret. >> HMAC_SHA256 would be sufficient but I have specified SHA512 to allow to >> directly derive 512bits which allows to have two 256bit keys with one >> HMAC operation (same pattern is used in BIP for the key/chaincode >> derivation). > > What's the rational for doing that "directly" rather than with two SHA256 > operations? (specifcially SHA256(0 . thing), SHA256(1 + thing) for the two > parts we need to derive) SHA256 and SHA512 are both from the SHA-2 family. I have specified SHA512 to (slightly) increase the brute-force security of the ecdh shared secret when knowing K_1 and K_2. And I assumed (haven't measured the required cpu cycles) that a single SHA512_HMAC is less expensive then two SHA256_HMAC. signature.asc Description: OpenPGP digital signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP 151 use of HMAC_SHA512
On Wed, Jun 29, 2016 at 08:34:06PM +0200, Jonas Schnelli via bitcoin-dev wrote: > > Based on previous crypto analysis result, the actual security of SHA512 > > is not significantly higher than SHA256. > > maybe we should consider SHA3? > > As far as I know the security of the symmetric cipher key mainly depends > on the PRNG and the ECDH scheme. > > The HMAC_SHA512 will be used to "drive" keys from the ECDH shared secret. > HMAC_SHA256 would be sufficient but I have specified SHA512 to allow to > directly derive 512bits which allows to have two 256bit keys with one > HMAC operation (same pattern is used in BIP for the key/chaincode > derivation). What's the rational for doing that "directly" rather than with two SHA256 operations? (specifcially SHA256(0 . thing), SHA256(1 + thing) for the two parts we need to derive) Reducing the # of basic cryptographic primitives you need to implement a standard needs is a good thing. -- https://petertodd.org 'peter'[:-1]@petertodd.org signature.asc Description: Digital signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP 151 use of HMAC_SHA512
Hi Ethan >> 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? No. Not to the ECDH negotiation. BIP151 specifies a flexible symmetric key cipher type negotiation, although, BIP151 only specifies chacha20-poly1...@openssh.com. Lets assume someone adds another symmetric cipher type after BIP151 has been deployed which has less strong security properties then chacha20-poly1305. If we don't include the ciphersuite-type in the key derivation HMAC, an attacker/MITM could in theory force both nodes to use the weaker symmetric cipher type. signature.asc Description: OpenPGP digital signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP 151 use of HMAC_SHA512
> Based on previous crypto analysis result, the actual security of SHA512 > is not significantly higher than SHA256. > maybe we should consider SHA3? As far as I know the security of the symmetric cipher key mainly depends on the PRNG and the ECDH scheme. The HMAC_SHA512 will be used to "drive" keys from the ECDH shared secret. HMAC_SHA256 would be sufficient but I have specified SHA512 to allow to directly derive 512bits which allows to have two 256bit keys with one HMAC operation (same pattern is used in BIP for the key/chaincode derivation). Keccak would be an alternative but we probably don't want to introduce another new hash type just for the encryption. signature.asc Description: OpenPGP digital signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP 151 use of HMAC_SHA512
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 wrote: > On Jun 29, 2016 07:05, "Ethan Heilman via bitcoin-dev" > 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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP 151 use of HMAC_SHA512
On Jun 29, 2016 07:05, "Ethan Heilman via bitcoin-dev" < bitcoin-dev@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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP 151 use of HMAC_SHA512
>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 wrote: > Jonas Schnelli 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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP 151 use of HMAC_SHA512
HMAC has proven security property. It is still secure even when underlying crypto hashing function has collision resistant weakness. For example, MD5 is considered completely insecure now, but HMAC-MD5 is still considered secure. When in doubt, we should always use HMAC for MAC(Message Authentication Code) rather than custom construction On Wed, Jun 29, 2016 at 9:00 AM, Rusty Russell via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Jonas Schnelli 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 > -- Xuesong (Arthur) Chen Senior Principle Engineer BlockChain Technologist BTCC ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP 151 use of HMAC_SHA512
Jonas Schnelli 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
Re: [bitcoin-dev] BIP 151 use of HMAC_SHA512
Based on previous crypto analysis result, the actual security of SHA512 is not significantly higher than SHA256. maybe we should consider SHA3? On Tue, Jun 28, 2016 at 3:19 PM, Jonas Schnelli via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > 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. > > > > [1] > > https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#child-key-derivation-ckd-functions > > > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > -- Xuesong (Arthur) Chen Senior Principle Engineer BlockChain Technologist BTCC ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP 151 use of HMAC_SHA512
> 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. [1] https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#child-key-derivation-ckd-functions signature.asc Description: OpenPGP digital signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] BIP 151 use of HMAC_SHA512
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") Thanks, Rusty. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
