# Are There Non Blockchain Usages of Ecdsa/Secp256k1?

fleeting

Considering that Hashicorp needs real world usages to support new cryptosystems, and that they don’t plan to support blockchain yet, this pull request was rejected.

I tried to rationalize this usage and looked for other usages of this algorithm using this curve.

Note that the curve secp256k1 not to be confused with the secp256r1, also known as P-256 (NIST) or prime256v1 (ASN OID).

I could find out that openssl tackle ECDSA.

The only Elliptic Curve algorithms that OpenSSL currently supports are Elliptic Curve Diffie Hellman (ECDH) for key agreement and Elliptic Curve Digital Signature Algorithm (ECDSA) for signing/verifying

And issuing the following command tells me that it supports both secp256k1 and secp256r1 curves.

openssl ecparam -list_curves|grep -e secp256 -e prime256

  secp256k1 : SECG curve over a 256 bit prime field
prime256v1: X9.62/SECG curve over a 256 bit prime field


But, looking for real world use cases of openssl with this curve gives me only bitcoin and ethereum usages.

There is one usage that appears to use secp256k1, but it sounds like they confuse it with P-256.

Generate ECDSA keys with the P-256 (secp256k1) curve

There is also another tutorial using secp256k1, but without telling whether they use it or not in real life. They don’t even advise to use it.

Use the following command to generate an EC parameters file of curve secp256k1:

$openssl ecparam -name secp256k1 -out secp256k1.pem Replace secp256k1 with any other name obtained from the openssl ecparam -list_curves command. Actually, they most likely copied, pasted and rephrased the openssl wiki. An EC parameters file can then be generated for any of the built-in named curves as follows:$ openssl ecparam -name secp256k1 -out secp256k1.pem

Replace secp256k1 in the above with whichever curve you are interested in.

So I guess it does not count either.

Then, trying to be more aggressive, with this request “openssl secp256k1 -bitcoin -ethereum -btc -eth”.

I still find people confusing it with P-256.

If you have concerns about writing the unencrypted private key to disk, you can do both the generation and encryption of the key in one step like so:

$openssl ecparam -genkey -name secp256k1 | openssl ec -aes256 -out privatekey.pem This generates a P-256 key, then prompts you for a passphrase. The key is then encrypted using AES256 and saved into privatekey.pem. And the others results are about playing with secp256k1, without indicating why (most likely to play with blockchain but without mentioning it). By trying a bit further, I found out that there was a hype in 2014 about a “better internet” using ECC. So I basically tried to find out what are the algorithms and curves used in the certificates installed in my machine. First, let’s expose the information out of one certificate. extract_curve ( ) { openssl x509 -in "$1" -text|gi -B 1 "nist cur"|{
do
echo -n "$line " done echo } }  Then, I run this other all the certificates installed on my machine. find /etc/ssl/certs/ -type l |while read cert do extract_curve "${cert}"
done | sort | uniq -c

     12 ASN1 OID: prime256v1 NIST CURVE: P-256
57 ASN1 OID: secp384r1 NIST CURVE: P-384


Still no luck, secp256k1 is not used, while secp256r1, is used by 12 certificates authorities and secp384r1 appears even more popular.

Finally, I can find out other people stating that secp256k1 is actually used only in the blockchain world. Even more narrow in the cryptocurrency community.

secp256k1 is used almost exclusively in the cryptocurrency community. Outside of that community, secp256k1 is a highly unusual curve to use. This means that it has a fairly narrow set of use-cases in which it is a reasonable default. This adds asymmetrical API risk to the API: users building cryptocurrency wallets will immediately know that they need secp256k1 and can dismiss the other choices, while users building other constructions (of whom there are vastly more) will now need to research and consider secp256k1 to validate whether it is suitable before they dismiss it. The burden of this new API falls much more heavily on the more-common use-cases. For better or worse, P-256 has much wider deployment than secp256k1, and therefore has an easier time justifying its presence in Swift Crypto than secp256k1 does.

Then, I decided to believe that secp256k1 is not used in contexts other than blockchain and understand (and agree with) the decision of Hashicorp of refusing this pull request.