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.

0260378aef

> 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](https://git.ekzyis.com/ekzyis/nip44/src/commit/ddde532a9e6c3abcf87c82104b4ea777c5b18b8e/nip44.go#L137-L150) and that I am [currently skipping tests](https://git.ekzyis.com/ekzyis/nip44/src/commit/ddde532a9e6c3abcf87c82104b4ea777c5b18b8e/nip44_test.go#L98) because I assumed that `secp256k1` keys are _always_ valid of strong. However, if they are generated using`secp256k1.PrivKeyFromBytes` they might not be valid or contain weaknesses.

See [this reply](https://stacker.news/items/377246) from me, hopefully it unconfuses you :)

bitdevs

waxwing commentary on twist attacks + bitcoin’s curve

niftynei

So I guess it must be this one?

https://github.com/decred/dcrd/blob/8208daf4c708454b408699d31ca923ef321637a5/dcrec/secp256k1/ecdh.go#L14C6-L14C26

What's input is a PubKey object, which I guess will be got by calling `ParsePubKey`, here?:

https://github.com/decred/dcrd/blob/8208daf4c708454b408699d31ca923ef321637a5/dcrec/secp256k1/pubkey.go#L104

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)