Switch to rust-secp256k1 from libsecp256k1

[tomusdrw]

It seems that currently we use libsecp256k1 in sp_core::ecdsa implementation. As I've been told, the main reason for that was because rust-secp256k1 wouldn't compile for WASM/no_std.

It seems it's not the case any more and rust-secp256k1 is more performant, has been audited and is more commonly used, hence I see no reasons for not switching to this.

[tomusdrw]

It seems that rust-secp256k1 might not have very good performance in intepreted WASM mode, so I think we should carefully benchmark this in both wasmtime and wasmi.

[bkchr]

We don't use the crate anywhere natively in WASM. We always call into native for this.

[tarcieri]

If you're considering alternatives to libsecp256k1, perhaps consider k256:

https://github.com/RustCrypto/elliptic-curves/tree/master/k256

It's an optimized pure Rust library with performance closer to the bitcoin-core C library:

Also even better performance on WASM.

The k256 crate implements complete Weierstrass formulas, and also supports lazy normalization and endomorphism optimizations (which are now free of patents). You can read more about it here:

https://iqlusion.blog/k256-crate-pure-rust-projective-secp256k1-library

[jakehemmerle]

I see @bkchr's PR solving this (at least partially) but it was closed and the branch was deleted. Was this because it needs an audit or another high-overhead reason, or was it just stale and incomplete?

[stale]

Hey, is anyone still working on this? Due to the inactivity this issue has been automatically marked as stale. It will be closed if no further activity occurs. Thank you for your contributions.

[jordy25519]

It seems libsecp256k1 doesn't implement RFC6979 which causes some issues for signature verification by ethereum libraries

[athei]

We don't use the crate anywhere natively in WASM. We always call into native for this.

Except when compiling, with full-crypto, right? :

substrate/primitives/core/Cargo.toml

Line 143 in 25eb7ac

"libsecp256k1",

[davxy]

If you're considering alternatives to libsecp256k1, perhaps consider k256:

https://github.com/RustCrypto/elliptic-curves/tree/master/k256

It's an optimized pure Rust library with performance closer to the bitcoin-core C library:

I've done some benchmarking using the latest releases of all the libraries that we are considering for secp256k1 ecdsa signature.

The results (here) are still aligned with the ones provided by tarcieri not so long ago.

So currently secp256k1 is faster by a factor of 3 compared to (compelling) the k256 pure Rust implementation.

@tarcieri are there any plans to reduce this gap?

I wonder if secp256k1 C implementation is faster because of some low level code trick or if the difference is more of algorithmical nature.

I see there is a (now closed) issue meant to address this here.

[tarcieri]

There are a few low hanging fruit optimizations left to pursue, like using wNAF form for verification, or precomputing basepoint tables. We have made some recent progress towards the latter.

[Srikarrao1]

What if I use both "libsecp256k1", "secp256k1" in , and we're still unable to achieve ECDSA state

[bkchr]

@Srikarrao1 I don't get your question?

[Srikarrao1]

I want to acheive functionality of ECDSA crate by integrating functions such as Signer, Verifier and Signature traits in substrate based primitives, appreciate your response!

[bkchr]

Still don't get it.