# Cryptographic Fundamentals of Blockchain
Modern cryptography leverages computer capabilities to make the power of certain mathematical functions available for practical use. Without modern cryptography, there would be no blockchain technology.
Therefore, anyone new to blockchains discovers frequent references to message signatures and other concepts related to cryptography. While this is not an extensive exploration of the topic and you will not deep dive into the mathematics, this section will demystify important concepts if they are new to you.
# Public and private keys
In public-key cryptographic systems, keys always come in pairs and offer various capabilities. The capabilities are based on cryptographic mathematics. As the name suggests, the public key is meant to be distributed while the private key is to be jealously guarded. Compare the key pairs to having your house address public but keeping the key to your house private.
The following example will help to better understand public/private keys, which you may know under the names:
- RSA
- PGP or GnuPG
This is like a password that is used to encrypt your private key on disk. If the private key was not encrypted, it would be at greater risk of theft. Since you are just testing here, you can put in nothing or just a simple word. Still remember that whenever you create keys in the future, you need to protect them with a proper password.
You may need openssl version 1.0 or a newer one.
Now take a look at scenarios in which public/private key pairs are useful.
# Encrypt and decrypt
Alice wants to send a message to Bob that is meant for Bob's eyes only:
- Bob gives Alice his public key.
- Alice uses Bob's public key to encrypt the message.
- Alice sends Bob the encrypted message.
- Bob decrypts the message with his private key.
Now look at the senario code-wise. For example, try the following:
If you receive an error, try with openssl rsautl
instead.
# Sign and verify
Alice wants to make sure that Bob's public announcement is indeed from Bob:
- Bob gives Alice his public key.
- Bob signs his announcement with his private key.
- Bob sends Alice his announcement and its signature.
- Alice verifies the signature with Bob's public key.
Back to the code example:
Which finally prints:
# Mix and match
It is possible to mix both conceptual ideas. For example:
- Alice encrypts her message with Bob's public key.
- Alice signs the encrypted file with her private key.
- Upon reception, Bob verifies the signature with Alice's public key to make sure the file came from Alice.
- Bob decrypts the file with his private key.
# Is this science or magic?
If these examples seem counter-intuitive it means you sense the mathematical shadow of public-key encryption. You do not have to understand the mathematics behind it at a deep level, but you must understand the properties and implications of using public-key cryptography.
Given four keys (A, B, C, and D), we can encrypt a message with three keys (A, B, and C) such that the fourth key (in this case, D) is required to decrypt it and is very hard to guess or discover. So, if Alice knows her private key and her public key and she also knows Bob's public key, she can encrypt a message that can only be understood by someone who knows Bob's private key.
Similarly, given knowledge of public and private keys, one can generate a signature (i.e. a character string) so that someone with a copy of the message and the signature can independently determine the public key of the entity that signed the message, proving that the signer knows the corresponding private key.
It is then possible to proceed with the understanding that signed messages from Alice could only come from someone with knowledge of Alice's private key, and messages that are encrypted for Bob can only be deciphered by Bob.
# Key management and public key infrastructure
If you look again at the Alice and Bob examples, you will notice that there is a vulnerability in "Bob gives Alice his public key". A malicious Charlie could intercept Bob's public key and pass on his own public key to Alice.
Key management and public key infrastructure (PKI) is an important aspect of cryptography that helps mitigate this risk.
# Cryptographic hash functions
Blockchain technology relies heavily on hash functions, as they help establish the so-called "chain of blocks".
All cryptographic hash functions fulfill several properties:
- Converts an input (a.k.a. the message) into an output (a.k.a the hash).
- Does the conversion in a reasonable amount of time.
- It is practically impossible to re-generate the message out of the hash.
- The tiniest change in the message changes the hash beyond recognition.
- It is practically impossible to find two different messages with the same hash.
With such a function, you can:
- Prove that you have a message without disclosing the content of the message, for instance:
- To prove you know your password.
- To prove you previously wrote a message.
- Be confident that the message was not altered.
- Index your messages.
# A closer look at a hash function
MD5 is such a hash function:
Which prints:
On Linux, this is md5sum
.
Now introduce a typo to see what happens (e.g. changing "jumps" to "jump"):
Which prints:
Notice how the two hashes have nothing in common other than their length, but length is identical for all MD5 hashes so it reveals nothing about the input.
This provides a convenient example, but MD5
is no longer considered a hard-to-crack hash function. Bitcoin uses SHA-256
. Ethereum uses Keccak-256
and Keccak-512
.
To summarize, this section has explored:
- How modern cryptography leverages computing to make complex mathematical functions useful on a practical level, providing the essential foundation for blockchain technology.
- How public/private key systems are used to encrypt and decrypt private messages across a public network, providing certainty to both parties that only the intended recipient can open them and that only the claimed sender can be the actual source.
- How cryptographic hash functions allow for such things as the one-way confirmation of data; for example, being able to check that a person has a particular piece of data without the necessity of actually sharing that data as part of the check.