You are on page 1of 7

Evaluation of secp256k1 as

Popular Alternative Curve

Christopher Allen, Principal Architect / Blockstream
CFRG Interim Meeting, Paris — April 30, 2017
What is secp256k1?
Variant of ECDSA: Improvements in secp256k1:
● ECDSA was created by NSA and is ● Significant performance improvements
defined in NIST 186-3 DSS Standard, over NIST-based ECDSA, which is
and uses the elliptic curve secp256r1 currently allowed for standards

● secp256k1 addressed concerns by ● Uses a Koblitz-like curve for efficient

cryptographic community as to computation, is often ~30% faster for
possible hidden parameters in the verification than ECDSA
ECDSA random coefficient
● Currently ~30% slower than
● Simpler structure, fewer choices, thus Ed25519-donna for signing, but
less ways for a malicious party to anticipating some future speed
introduce vulnerabilities improvements
Why is secp256k1 important?
De-facto standard for blockchains Significant usage
● Used by Bitcoin, Ethereum, Zcash and ● In active use since 2009
many other blockchains
● Multiple interoperable
● In Bitcoin alone, ~260K transactions a implementations
day for ~$390M volume per day
● Multiple languages: libsecp256k1 (C),
● Protecting $25B+ markets! Bouncy Castle (Java VM), Crypto++
(C++), secp256k1-go (Go),
● "Largest Bug Bounty in the World!" tiny-secp256k1 (Rust), elliptic-curve-js
● May not be most current work in
elliptic curve, but "good enough"
libsecp256k1: fast, strong, well-reviewed, well-tested
Most used implementation: libsecp256k1 (C)
● Fast: validation of signatures increased ● Special compilable mode that changes
5x over original OpenSSL a constant to end up with a very small
group, and exhaustive tests that all
● Significant review and high test assumptions remain true
● Test cases for the scalar code that were
● Hand verifiable proof of correctness extracted from a set of 1 trillion
for the field multiplication algorithm randomly generated tests which give
very high coverage, and work in
● Computer verified proof of correctness
progress to algebraically derive cases
for group addition formulae
that trigger the (nearly) unreachable
remaining ones
Why not use a more current standard?

Why not use Ed25519 or a more recent

curve? ● Ed25519 is non-linear, thus there have
● More modern curves did not exist or been no standards for HD
were not well studied when first (Hierarchical Deterministic) Key
blockchains began derivation used by most blockchains

● Due to stability required by consensus

protocols and financial code,
established blockchains can't easily
switch to other curves
Why allow secp256k1 for Standards?
Blockchain standards are local and ad-hoc Where to be used?
● Many blockchain communities are ● For interoperability reasons, greatest
already using secp256k1 with JWT. need is in W3C to support secp256k1
However, all are non-conformant to in Web Payments & Verifiable Claims
published standard Working Groups

● We can improve security by making ● These W3C groups use IETF JOSE
secp256k1-based implementations standards for such as JWS for JSON
conform to standards Signing and Encryption.

● Support of secp256k1 brings ● Curve not be requested for all existing

blockchain communities into standards standards, for instance no requests to
efforts secp256k1 add to TLS or SSH.
What do we need to do get CFRG to evaluate and
approve secp256k1 for optional use in IETF standards?