Craig Wright reveals Bitcoin key verification process

“Signing with Jean-Paul Sartre has a different meaning than signing with Jean-Paul Sartre, Nobel Prize winner.

—Jean-Paul Sartre, 1964"

I remember reading this sentence many years ago and feeling uncomfortable since then. However, many years later, after all the ups and downs of these years, I feel calm when I think back to this sentence. Signing with Craig Wright is different from signing with Craig Wright, Satoshi Nakamoto.

Although I know this is the truth, deep down I don't want it to be this way.

IFdyaWdodCwgaXQgaXMgbm90IHRoZSBzYW1lIGFzIGlmIEkgc2lnbiBDcmFpZyBXcmlnaHQsIFNh

dG9zaGkuCgo=

I have stared at my screen for hours and still cannot find the words to express the deep gratitude I feel for those who have supported Bitcoin from the beginning - too many to list. You have dedicated your youth and work, sacrificed relationships and downtime for years, and are still working on this open source project that may not have achieved anything, and are still working on it. The passion, wisdom and perseverance of this community has taken on my contribution, nurtured it, embraced it, and brought it to life. You have brought a great gift to the world, and for that, I am deeply grateful.

Rest assured, I have not been idle during these years. Since then, after distancing myself from the Satoshi persona, I have put all my efforts into research. I have remained silent, but never absent from Bitcoin activities. I am collaborating with a special group and look forward to sharing our results when the time is right.

Satoshi Nakamoto is dead.

But this is just the beginning.

Key Verification

In the rest of this post, I will explain the key verification process.

In order to ensure that we can successfully sign and verify messages using the correct elliptic curve parameters for OpenSSL, we must first ensure that the secp256k1 curve is loaded successfully. This is not the default on Centos Linux. I will not go into detail here. I will point out that RPMForge maintains patched binaries. If you are using Centos like me, my recommendation is to download the source and patches from the OpenSSL website.

Readers are advised to read the following websites:

•https://wiki.openssl.org/index.php/Command_Line_Elliptic_Curve_Operations

•http://www.secg.org/sec2-v2.pdf

•https://www.openssl.org/

•https://www.bfccomputing.com/bitcoin-and-curve-secp256k1-on-fedora/

The first stage will explain the hash function. In the figure below we show a file called "sn7-message.txt".

The series of hexadecimal values ​​shown above represent the SHA256 hash of an input value. A good hash algorithm will produce a large set of values ​​that cannot be determined in advance. The amount of information and all the possible permutations will always exceed the scope of a simulation that can produce the output from any hash function, but there will always be collisions. Given the current state of the art, it is not feasible to find a set of input values ​​that produce the same output value, which is what ensures the usefulness and security of hash functions such as SHA256.

The maximum amount of information provided by the SHA256 algorithm is (2^128−1) bits while returning 32 bytes or 256 bits as output. The amount of information that can be fed into the SHA256 hash function is (2^128−1)! The possible input values ​​range from 0 bits to the maximum value we can accept as noted above.

When determining the possible range of collisions, we have a binomial coefficient ( n ) that determines the permutations through combinatorics.

I will go into more detail about the math involved in collision detection in a later post. It is important to note that while every hash has an incredible number of collisions, the probability of finding two collisions or determining them in advance is infinitesimally small.

Hashing

Hash functions are relatively simple and can be done by hand. Of course this masks the complexity of reversing hash functions. A good hash function is simple to use, but not easy to reverse. The following figure shows the Linux hash program "sha256sum" in action. The program returns a unique value for a fixed set of inputs.

In the figure above, we have run the program on several files, one of which we are using in OpenSSL signing. This special file is called Sartre. The contents of the document are shown below:

The digital signature algorithm signs the hash of the message. Although it is possible to sign the message, signing the hash makes it possible to ensure the integrity of the message and verify whether the message has changed. Even if a space or a period is changed, the hash will be fundamentally different from the original return value.

In order to write this value and save it to a file, we can use the Linux command, xxd. This will write the ASCII value to a hexadecimal binary file. By typing the following command, we can write a series of zeros to a file called "file.name".

 echo '000...000' | xxd -r -p > file.name

To do this, we can transform the string received as the output from the hash algorithm into a hex encoded file. We can sign and verify this message. It is important to verify the string you added to the echo command above. If a single digit is mistyped, the message cannot be verified.

Public Key

In order to verify a digitally signed message, we need a number of conditions, including:

•algorithm

• The public key of the signer we wish to verify

•Signed message

• Digitally sign documents

In the first part, the required algorithms can be obtained by installing OpenSSL which has the secp256k1 curve patch merged. The above steps also include creating a hash message. The next part includes using the ECDSA public key.

In this step, I used a public-private key pair stored in a PEM file in OpenSSL. David Derosa has written a great page that defines the creation of OpenSSL elliptic curve key pairs. In the image above you can see the specific PEM formatted public key that is closely related to the key pair used in message signing. Reading through David's page will provide the reader with all the details on how the private key used in Bitcoin transactions can be formatted as a PEM file. The page details the creation of a new private key rather than how to import an existing private key into OpenSSL. I will cover this additional process and demonstrate how an existing private key pair based on elliptic curve cryptography can be imported into an ASN.1 format for direct use with OpenSSL.

The command to export our public key is as follows:

openssl ec -in sn-pub.pem -pubin -text -noout

0411db93e1dcdb8a016b49840f8c53

bc1eb68a382e97b1482ecad7b148a6

909a5cb2e0eaddfb84ccf9744464f8

2e160bfa9b8b64f9d4c03f999b8643

f656b412a3

These return strings are public key values ​​used by programs including Bitcoin signature functions for verification and addressing.

Casascius has developed a tool that can help you decode the public key and return the associated Bitcoin address.

sign

The process of digitally signing a message using OpenSSL requires that the party signing the message has access to a private key. In recent days, I have used 10 private keys associated with Bitcoin addresses. These have been loaded into the SPV wallet Electrum, where I signed messages that were not chosen by me but by others. In some cases, we ensured the integrity of the process by downloading a new version of Electrum.

The version of electrum I am running is Centos Linux v7, running through Python

Signature Verification

The last step is signing. We will use the following command to convert the base64 signature into a file format that can be loaded into OpenSSL.

>> base64 –decode signature > sig.asn1 & openssl dgst -verify sn-pub.pem -signature sig.asn1 sn7-message.txt

The signature file we want to verify includes the following data:

————————- Signature File ————————-

MEUCIQDBKn1Uly8m0UyzETObUSL4wYdBfd4ejvtoQfVcNCIK4AIgZmMsXNQWHvo6KDd2Tu6euEl1

3VTC3ihl6XUlhcU+fM4=

————————- End Signature ————————–

As shown in the figure below, we show the signature file. When saving the file, you can cut and paste the encoded signature and insert it into a saved file by using an editing program such as Vim.

Some scripts

To simplify the program, I have included two shell script files. For variations of these scripts, see sites such as Enrico Zimuel's, which is not specifically focused on elliptic curve cryptography, but it is not difficult to update his code and use it with a Bitcoin-based system.

sign

I've included the signing script below so you can test it at your leisure. To use this script, the input includes the variable <file>, which can be used to represent the file you wish to sign using the selected <private_key>. In this command, the <private_key> variable represents the file that contains the private key used to sign the message.

 EcDSA.Sign.sh <file> <private_key>

verify

We can use a similar procedure to verify the signature we created, using the following script.

 EcDSA.Verify.sh <file> <signature> <public_key>

In this command line, the variable <file> represents the name of the file we want to verify. The variable <signature> represents the file where we save the signature (encoded using Base64). The last variable <public_key> contains the public key in PEM format. These files can be used together, and if they are all valid and correct, then the digital signature can be successfully verified.

Select Format

The signature format used by Bitcoin is based on the DER encoding. Other methods used to encode raw code have evolved significantly over the past 7 years. The choice of using DER encoding for signatures and other information was based on the desire to ensure that information can be shared between incompatible systems. It is not the most efficient way to store information, but it does allow completely different systems to communicate effectively.

Like many open source projects, OpenSSL is poorly documented in many areas. Bitcoin addressing and storage of key pairs could be more efficient, and the code has been updated to ensure this is the case.

Safety has always been a function of risk rather than an absolute.