0 sats \ 3 replies \ @0260378aef 4 Jan \ parent \ on: waxwing commentary on twist attacks + bitcoin’s curve bitdevs
I guess it's just my lack of knowledge of something about golang? But I can't find github.com/decred/dcrd/dcrec/secp256k1/v4 , nor can I find a v4 (or v4.*) branch?
So I guess it must be this one?
What's input is a PubKey object, which I guess will be got by calling
ParsePubKey, here?:and it is checking that it's a valid point (actually, it's also checking in the case when the point is uncompressed, as you'd hope/expect. (line 141)
reply
So I guess it must be this one?
Sorry, using
GenerateSharedSecret was confusing. I didn't mean the function in secpk256k1. I meant the function in my NIP-44 library and that I am currently skipping tests because I assumed that secp256k1 keys are always valid of strong. However, if they are generated usingsecp256k1.PrivKeyFromBytes they might not be valid or contain weaknesses.See this reply from me, hopefully it unconfuses you :)
reply
No, I don't think there was any confusion in that second point. I read the function in your library, then I went looking for
secp256k1.GenerateShared Secret that you use, there.I don't think there's any issue apart from the one you mention about how the private key is generated, i.e. what they warn about in your original comment. (and this is always a big concern to address, whether doing ECDH or anything else).
And as for pubkeys, which are the only source of a "twist attack" type concern, The
secp256k1.PubKey object is almost always going to be generated from ParsePubKey right? The only other way is via a constructor, and there is no concern there anyway.reply