ECDSA — Satoshi’s Genius Selection or A Burden on A More Distributed and Resilent World?

ECDSA — Satoshi’s Genius Selection or A Burden on A More Distributed and Resilient World?

Did Satoshi get it right?

Out with the old (DSA), in with the new (ECDSA)

And so, over a decade ago, Satoshi Nakamoto selected the secp256k1 elliptic curve for his new invention: Bitcoin. At the core of this was the selection of a random 256-bit value (sk — the private key), and then the creation of a public key (pub = sk.G). The private key could be used to digitally sign a transaction, and the public key would then prove it. It was just so simple, and where the elliptic curve calculations were so much faster than the ageing RSA method and its related signature method: DSA (Digital Signature Algorithm).

Thus, all Bitcoin owners need to do is keep their private key safe, and they can trade with a cryptocurrency without the need for banks to provide that trust for them. But, what was needed was an efficient digital signature method … and so Satoshi turned to ECDSA (Elliptic Curve Digital Signature Algorithm), and then magic happened. With this, Bob could take a hash of the transaction, and then create a digital signature with his private key. Everyone could then check this transaction using his public key. It was just beautiful in its simplicity and in the way it could run on devices with limited processing requirements. The days of large and cumbersome RSA key pairs were passed, and where ECC (Elliptic Curve Cryptography) stepped up to secure our world.

An outline of the method is here:

And, so, we end up with a wonderfully simple signature method. Overall it has had some problems over the years, such as when we do not use a random number within the signature. These problems were generally caused by developers not doing things properly, but it has generally worked well. In fact, it has supported the growth of Bitcoin and Ethereum, and is used in every single transaction within these public ledgers.

Example

In the following we take a message, and generate a private key and then generate a public key and a message signature:

https://asecuritysite.com/signatures/ecdsa_rs2

The result is:

=== Message ===
Msg=Hello 123
Hash=859e38d581e214dc7c8c871c425642913363a829065cf4acddd120ed5391b04b

=== Private key ===
Private key=1468e552139b876a6213906b9abccd7d0b6146d6739b026fc0d14fb5828412bf
Curve=P-256k1

=== Public key (X,Y) ===
X=22354903762467115455336961068808839927696442283074381201648317561272034062273 Y=25615965051428036248554568888679441886491629079681786731138051481219514472097
  Hex: X=316c6d59567275de266aa82a30ba3e1cd408246a988b431f13d244e34bc2efc1 Y=38a21f573ed9ad9c8dd9107d8954d24b10357beee5b9df470f289be9a28b96a1

=== Signature (R,S) ===
R=64011752400658164386261725558647824411442145209632765546172256832159951283212 S=5141451411039917952430993522136627387506297060206744149469460189928130583022
 Hex: R=8d855e3135408528319c48b9e77bff82dfdf18bf9c65011df8725ab5823ae40c S=b5df557f90fd5697986806186497392d9bdf29fb6dc198775a381d900c399ee
Signature verifies

In this, we see that we have a 256-bit private key, and a public key which is a point on the secp256k1 curve. The output is two values: R and S. Once we use the message, the public key points, and the values of R and S, we should be able to determine the validity of the signature.

Now, we can test these values for x,y, r and s: here. If we now change the y value to be “38a21f573ed9ad9c8dd9107d8954d24b10357beee5b9df470f289be9a28b96a0”: , we now get an invalid signature: here. The following video shows the change of one value (in this case, the y value of the public key is changed):

Is it fit for a distributed Internet?

But, we have a small problem. These days we are now splitting our encryption keys into secret shares, and then distribute these to a number of trusted parties. When required, we can then rebuild them. While this works for distributing the keys, it works less well for ECDSA, as the algorithm does not naturally support this splitting, and for each party to generate part of the signature based on their key share.

Other signature methods, such as Schnorr, do support this. So if Satoshi had selected the Schnorr signature method, we would be fine, and where we can distribute the shares of the key. Then each part of the signature could be generated by each of the parties and then reconstructed from the share of the signature. This would define a world of MPC — Multiparty Computation. While it is difficult to create a split of ECDSA from the secret shares of a private key, some researchers have been working on the problem, and here’s one solution:

Conclusions

To Satoshi … well done! Satoshi properly designed a digital system that was inherently secure and trusted. But we now need to distribute things, and ECDSA is a bit of a roadblock. One thing that is for sure, though, is that the research community will solve it, and we will move to distributed signing, and where no one party actually has the private key used. This will not only bring improved security but will bring resilience. If the recent AWS and Facebook outages show one thing, is that we now need a distributed infrastructure and one which is resilient to a failure in any part of it.

Asecuritysite is provided free and without adverts. If you want to support its development and get access to this blog, subscribe here: