Rationale for ecdh_skip_hash_extract_x_and_y

[mikekelly]

This libarary is great, I really like the minimalist API but I'm having interoperability issues using it for ECDH.

I believe it is due to PrivateKey.sharedSecret using ecdh_skip_hash_extract_x_and_y

K1/Sources/K1/K1/Keys/PrivateKey/PrivateKey/PrivateKey+Bridge+To+C.swift

Line 144 in 89cac3e

ecdh_skip_hash_extract_x_and_y, // hashfp

The result is Data that when put through SHA256.hash produces a inconsistent result from libraries like this:

https://github.com/bitcoin-core/secp256k1/blob/185a6af22792531a629959834fff9257e396abb5/src/modules/ecdh/main_impl.h#L13-L24

I was wondering if this was an intentional design decision and what the rationale was?

[Sajjon]

👋 thanks a lot! Thanks for this, will investigate next week! Can't remember now why I did it like that. Can add parameter to swift function maybe? So the hash function can be chosen.

[mikekelly]

yeah, combined with an enum of the available functions (defaulting to .ecdh_skip_hash_extract_x_and_y, so the API doesn't break) would be a nice API :)

[Sajjon]

@mikekelly First of all, so so sorry for slowest response every! I was busy with other work. In #7 I've solved this issue, I now vendor three different ECDH variants, one of which is CryptoKit compatible, because it returns CryptoKit's SharedSecret struct which is really nice, since offers KDFs!

One which follows standards libsecp256k1 and lastly the old one (custom, no hash), please see the PR #7 for details.

I will make a new release 0.0.9 with these new APIs