Public and Private Keys

Asymmetric cryptographic algorithms were first developed in the 1970s and are fundamental to so many of the technologies we use today. It’s used on any secured page on the internet, on your cell phone, at your bank, etc.

The first asymmetric algorithms:

  • Diffie–Hellman key exchange
    • 1976
  • RSA (Rivest–Shamir–Adleman)
    • 1978

With asymmetric cryptography, instead of having one key, each party has two keys: a public key and a private key.

How this works is quite interesting. Alice and Bob can exchange public keys with each other in the open. It does not matter if Charlie obtains a copy of the public keys; all he can do with those keys is encrypted a message to Alice or Bob.

With Bob’s public key, Alice can encrypt her message to him and transmit it. Charlie, even having both public keys, cannot decipher the message. The only person who can decipher the message is someone in possession of Bob’s private key, in this case, only Bob can do this.

Public Keys:

  • Can be shared publicly.
  • Can be used to encrypt a message to another party.
    • Bob’s public key can be used to encrypt a message to Bob that only he can decipher.

Private Keys:

  • It is infeasible to reverse engineer a private key from a public key.
  • Are the only keys that can be used to decrypt a message.
  • Need to be kept strictly private.

Bob can also use Alice’s public key to encrypt a message to Alice.

Public keys and encrypted messages can now be transmitted in the open and our key thief here, Charlie, will still be unable to read the contents of the message.

Asymmetric cryptography is an incredibly powerful tool that can be used for a wide variety of applications.

The first use case is using this technology to encrypt and decrypt messages! However, the bitcoin software makes use of this technology to sign and verify messages, or more specifically, transactions.

Encrypting vs. Signing vs. Hashing

Bitcoin, and other cryptocurrencies, are built on cryptography, but actually very little “encryption” is done in the Bitcoin protocol while signing and hashing is used extensively. Let’s be sure we understand the difference. Below are rough explanations of these three related yet different functions.

Encryption – Scrambling data so that only entities with access to the keys will be able to decipher the message.

Signing – Taking data and producing from it a “signature,” another piece of data, that could have only have come from the entity controlling a certain private key.

Hashing – Creating a unique identifier for a specific piece of data.

Let’s take just a quick look at how the signing, and the verifying of those signatures works on the Bitcoin network.

Bitcoin uses elliptic curve cryptography, ECDSA, or more specifically the SECP256k1 curve.

Alice’s wallet will produce a transaction sending funds from an address she controls to an address Bob controls. This transaction data is signed with Alice’s private key. This produces a signature that proves Alice, or anyone in possession of her private key, has authorized the transfer.

To sign a transaction in Bitcoin, the data is first hashed (which we discussed in Enter the Blockchain Part I) then ran through the encryption algorithm which uses the private key to produce a signature.

When trying to verify that signature, you’ll need the transaction data that was signed. In the case of Bitcoin, that would be the transaction hash, the signature, and the public key. That data is then run through a validation algorithm which generally returns a true or false response.

Cryptography is very much a skill all its own separate from software development. There is a saying in the crypto world, “don’t roll your own crypto.” This phrase expresses the idea that it is very risky to attempt to build your own cryptography tools. There are many tried and tested libraries out there for signing and verifying signatures.

And now that we’ve covered some basics, we’ll be diving into decentralization and the functioning of decentralized networks in the next lesson.

Further reading: