crypto/secp256k1: Remove btcsuite intermediary.

[davecgh]

This updates the core/crypto/secp256k1 code to make use of the dcrec/secp256k1/v4 module directly instead of using btcec/v2 which itself is now just a shim around dcrec/secp256k1/v4 anyway.

This has the benefit of removing the additional transitive github.com/btcsuite/btcd/chaincfg/chainhash dependency since dcrec/secp256k1/v4 is its own module and does not rely on it.

It also updates to the latest v4.1.0 release which implements direct key generation and has some other nice optimizations that speed up signature verification as compared to the v4.0.1 release.

---

This was originally opened as libp2p/go-libp2p-core#280 and is being reopened here as requested.

Also, per discussion on the referenced PR, I confirmed that this is actually not a breaking change to the API despite changing the type aliases because the types in btcec/v2 are themselves just type aliases to the same underlying type this changes them to. For example, see the btcec/v2.PrivateKey type declaration which is an alias for dcrec/secp256k1/v4.PrivateKey. The same is true for btcec/v2.PublicKey.

In order to check that is indeed the case, I intentionally kept the type assertion in KeyPairFromStdKey as *btcec.PrivateKey and ran the TestKeyPairFromKey test which generates the key with secp256k1.GeneratePrivateKey (which is actually a *secp256k1.PrivateKey) and then calls KeyPairFromStdKey with it to ensure they are considered identical by the compiler.

Here is the diff relative to this PR to be more concrete about what I just explained:

diff --git a/core/crypto/key_not_openssl.go b/core/crypto/key_not_openssl.go
index 00324675..0f446c0f 100644
--- a/core/crypto/key_not_openssl.go
+++ b/core/crypto/key_not_openssl.go
@@ -9,7 +9,7 @@ import (
        "crypto/ed25519"
        "crypto/rsa"

-       "github.com/decred/dcrd/dcrec/secp256k1/v4"
+       "github.com/btcsuite/btcd/btcec/v2"
 )

 // KeyPairFromStdKey wraps standard library (and secp256k1) private keys in libp2p/go-libp2p/core/crypto keys
@@ -30,7 +30,7 @@ func KeyPairFromStdKey(priv crypto.PrivateKey) (PrivKey, PubKey, error) {
                pub, _ := pubIfc.(ed25519.PublicKey)
                return &Ed25519PrivateKey{*p}, &Ed25519PublicKey{pub}, nil

-       case *secp256k1.PrivateKey:
+       case *btcec.PrivateKey:
                sPriv := Secp256k1PrivateKey(*p)
                sPub := Secp256k1PublicKey(*p.PubKey())
                return &sPriv, &sPub, nil
diff --git a/go.mod b/go.mod
index 15f490a9..bc7f4e5e 100644
--- a/go.mod
+++ b/go.mod
@@ -4,6 +4,7 @@ go 1.18
 
 require (
        github.com/benbjohnson/clock v1.3.0
+       github.com/btcsuite/btcd/btcec/v2 v2.2.0
        github.com/davidlazar/go-crypto v0.0.0-20200604182044-b73af7476f6c
        github.com/decred/dcrd/dcrec/secp256k1/v4 v4.1.0
        github.com/flynn/noise v1.0.0

$ go test -run=TestKeyPairFromKey
PASS
ok      github.com/libp2p/go-libp2p/core/crypto 0.474s

---

Closes libp2p/go-libp2p-core#11.

[marten-seemann]

LGTM.

[MarcoPolo]

Nice, thanks for this!

[Jorropo]

LGTM thx (even tho it's a bit late)

[Jorropo]

I was actually self debating doing this while making #1686 but didn't because I liked that I didn't actually touched any of core/crypto's code.
Next time if similar thing happen since this is related you can ping me. 🙂

[davecgh]

@Jorropo Sure thing. I agree that it makes more sense to have it as a separate PR like this versus doing it as a part of #1686. I typically am very much in favor of keeping things more isolated and methodical versus commingling concerns in a single PR. Having it separate means 1686 is able to focus solely on supporting boring as a backend.

[Jorropo]

Having it separate means 1686 is able to focus solely on supporting boring as a backend.

All I had to do is bump secp256k1 to v4.1.0, which you did already.
Everything boring related in #1686 is the testsuite.

[davecgh]

I noticed the CI checks seem to have timed out. I just restored the branch if you're planning on triggering them to run again.