0 sats \ 2 replies \ @03bebce944 3 Jan \ parent \ on: waxwing commentary on twist attacks + bitcoin’s curve bitdevs
have only dabbled in this stuff (took some crypto courses in college), but from my understanding: Bitcoin uses compressed keys everywhere, and decompression has a built in check to make sure things are on the curve: https://github.com/decred/dcrd/blob/dcrec/secp256k1/v4.2.0/dcrec/secp256k1/pubkey.go#L175
That's the
ParsePubKey function. But if I am not using this function but provide my own bytes, then the secp256k1 package does not make sure. At least that's how I understand this warning for the function PrivKeyFromBytes.WARNING: This means passing a slice with more than 32 bytes is truncated and that truncated value is reduced modulo N. Further, 0 is not a valid private key. It is up to the caller to provide a value in the appropriate range of [1, N-1]. Failure to do so will either result in an invalid private key or potentially weak private keys that have bias that could be exploited.
Also, bitcoin does not use the github.com/decred/dcrd/dcrec/secp256k1/v4 package. It uses libsecp256k1 since it's written in C. LND however is written in golang and uses the aforementioned package.
reply
The privatekey -> pubkey function is “fine”. It isn’t a vector for being subjected to twist attack.
The pubkey you get back from this function will be on the curve as it’s internally munged to be. The risk is that it won’t “match” the private key that you provided.
The attack specifically requires you not to verify a pubkey you’ve been given is on the curve.
am I not using secp256k1 just because the library has a vulnerability?
Technically, yes 😂 in this case the bug is the library is not living up to its name 🤷
reply