from Investopedia

Understanding Blockchain — Foundation

“Bit Coin” and “Blockchain Technology”, are 2 of the most frequently heard words within technical communities nowadays; especially among the ones attached with banking and finance. However, the lack of in-depth understanding of foundational concepts behind “blockchain technology”, has made understanding “blockchain” difficult.

This article explains several prerequisite concepts helpful for understanding “how blockchain technology works”.

1. Ledger (simplified in-line with the context of understanding blockchain)
2. Cryptographic Hash Functions
3. Symmetric & Asymmetric Key Cryptography
4. Digital Signatures
5. De-centralized Network

Ledger

In the context of financial accounting; the main accounting record of a company or organization is referred as the “ledger”. The ledger will indicate;

1. all the “transactions” done by the company up to a certain date
2. how did the amounts owing to the company and each stakeholder, change during each transaction
3. the remaining amounts owed by the company and its stakeholders, in relation to all business upon completion of the last recorded transaction

To aid understanding blockchain, let’s go through a simplified example of a ledger formed between 4 friends; Alice, Bob, Casey and Daniel.

Alice, Bob, Casey and Daniel have $40, $55, $65 and $45 respectively in the initial ledger.

Alice pays Bob $20. This is the first “transaction” done in this ledger. Upon completion of the transaction the amounts owned by Alice is reduced to $20. Also the amount owned by Bob is increased to $75. The amounts owned by Casey and Daniel remain the same as they are not included in this “transaction”.

Similarly the “second transaction” happens between Bob and Casey and their respective amounts are updated upon completing the “second transaction”.

The third transaction is between Casey and Daniel.

The fourth transaction is between Daniel and Alice. Hence our ledger has recorded a “transaction history” of 4 transactions, since the start. You can find out the current amounts owned by each stakeholder of this ledger from the final result. You can also calculate the amounts owned by each stakeholder before and after each transaction in the “transaction history” (i.e. the “sequential” record of transactions) by going back and forth.

Cryptographic Hash Functions

Figure 1 — Cryptographic Hash Function

A cryptographic hash function is a special computer algorithm, which takes a text input of any length and returns a random output text (also called the “hash” or “message digest”) of constant length. Note that for a “given specific input text”, the function must always return the “same hash” every time you run it. (e.g. Figure 2 — for the input string “Hi”, our hash function must always return the given output “hash”, every time when we run our hash function with input “Hi”)

Figure 2 — Sample Inputs & Outputs related with a Cryptographic Hash Function

Also note that the length (i.e. number of characters) of the output string (i.e. “hash”) is always constant irrespective of the length of the input string (see Figure 2).

Figure 3 — Sample Inputs & Outputs related with a Cryptographic Hash Function

A cryptographic hash function must satisfy several characteristics in order to be “useful”.

1. It must be mathematically impossible (or at least computationally extremely expensive) to obtain the original input text by using the output “hash” (see Figure 2 and Figure 3 — it has to be impossible to obtain the “input” texts by using their corresponding “hash”es).
2. The generated “hash” (or “digest”) must be significantly different even between 2 different inputs those are minimally different (in Figure 3, observe the significant difference between the output “hash”es even during a slight change of the corresponding “input” text)
3. It has to be “computationally infeasible” to generate a “desired arbitrary hash” by using “different modified input texts”.

One important characteristic that cannot be avoided from a cryptographic hash function is the presence of collisions. The reason for this is that the hash function has to return a fixed length “digest” for any given input text.

Figure 4 — Hash Function and Collision

Figure 4, illustrates how collisions occur by using a simplified hash function that returns only 16 different hashes. Of course, by careful analysis it could be determined that a simplified hash function as in Figure 4, won’t be able to satisfy all the 3 characteristics of a “useful” hash function. Why? For instance, since we have only 16 different possible “hash”es; it will be easier to find out a modified input text that provides a desired hash, violating 3rd characteristic of a “useful” hash function.

Hence decreasing the probability for occurring a collision helps making a hash function “useful”. So how can we make a hash function generate a large set of different “hash”es (leading to lesser collisions)? We can do 2 things.

1. Increase the size of the character set used to generate the output “hash”
2. Increase the length (number of characters) of the generated “hash”

For instance if we use an alpha-numeric character set (a-zA-Z0–9) and generate “hash”es of length 10; then our hash function is able to generate 62¹⁰ different “hash”es, leading to less collisions (62 = 26 capitals + 26 simples + 10 numeric digits).

Do we have real implementations of “useful cryptographic hash functions” as described in this section? MD5 and SHA-1 are 2 of the well-known and widely used “useful” cryptographic hash functions.

Symmetric & Asymmetric Key Cryptography

Cryptography describes different ways on how to exchange secret messages between 2 or more parties, so that any non-related party in the middle is unable to know/understand the actual content of the secret message, although they can access the message. In order to achieve this objective the message sender will “encrypt” the plain readable secret message (i.e. “plaintext”) to an unreadable message (i.e. “ciphertext”) using a unique “encryption key” and a publicly known “encryption algorithm”. The message receiver will convert (i.e. “decrypt”) the received unreadable “ciphertext” back to original readable message using a corresponding unique “decryption key” (not necessarily equal to the unique “encryption key”) and a publicly known “decryption algorithm”. (see Figure 5)

Figure 5 — Encryption and Decryption

Note that although any non-related party (other than the sender and receiver) can access the “ciphertext” as well as the “encryption/decryption algorithms”, they are still unable to “decrypt” the “ciphertext” and view the actual message “plaintext” content; since they don’t know the full information related to unique encryption/decryption “key”s exchanged between the sender and the receiver.

Cryptography has 2 broad domains depending on how this encryption and decryption “key”s are exchanged between the sender and the receiver.

1. Symmetric Key Cryptography
2. Asymmetric Key Cryptography

Figure 6 — Symmetric Key Cryptography

In symmetric key cryptography, the “encryption key” and “decryption key” exchanged between the sender and receiver are the SAME. (see Figure 6) Hence, both parties (i.e. the sender and receiver) need to have an agreement before the secret message communication, for a common key used during encryption and decryption. Examples of well-known and widely used symmetric key encryption algorithm implementations are DES and AES.

Figure 7 — Symmetric Key Distribution Problem

Although symmetric key cryptography algorithms are computationally less expensive comparing to asymmetric key algorithms; their main problem is managing the distribution of secret keys (since the sender and receiver has to exchange a common secret “key” prior to their secret communication). As you can see in Figure 7, for establishing 3 different private message channels between 3 people (i.e. 3 parties) we need 3 different symmetric encryption “key”s. For 4 people it is increased to 6 different keys, for 6 people 15 different keys and for n people (n / 2) * (n — 1) different keys.

In asymmetric key cryptography, for each party involved in communicating secret messages; we generate 2 keys (also called a “key pair”) to be used for encryption and decryption of data. This “key pair” has the below characteristics.

1. If you encrypt a plaintext message using any of the keys, it could be decrypted ONLY by using the other key.
2. If you know one of the keys of a “key pair”, you still cannot derive (or at least it is computationally infeasible to derive) the other key based on the key you have (or by any other means such as using pairs of sample “plaintext” and “ciphertext”)

Once an asymmetric “key pair” is generated, one of the 2 keys are kept in private with the generated party (called the “private key”) and the other key is published, so that it is known by everyone (called the “public key”). Examples of well-known and widely used asymmetric key encryption algorithm implementations are RSA and Elliptic Curve.

Figure 8— Public Key and Private Key

Figure 8 illustrates, 2 scenarios about using private key and public key during encryption and decryption.

1. Encrypt plaintext with private key and decrypt back with public key — Refer to Figure 9, where Alice and Bob are 2 people having their own “key pair”s. Alice’s and Bob’s “public key”s are known by everyone (i.e. Alice, Bob and Eve). But Alice’s “private key” is only known to Alice. Bob’s “private key” is only known to Bob. If Alice encrypts any plaintext with her “private key”, both Bob and Eve can decrypt it using Alice’s “public key”. If properly decrypted they (Bob and Eve) become certain that this plaintext was sent by Alice, since Alice is the only person who knows about her “private key”.
2. Encrypt plaintext with public key and decrypt back with private key — Referring back to Figure 9, if Alice wants to send a confidential message to Bob (without it being seen by Eve) she can encrypt the message with Bob’s “public key”. Since the message can be only decrypted with Bob’s “private key” and only Bob has it, Bob will be the only person who is able to decrypt the message. But the issue here is that Bob is not sure whether the message was actually sent by Alice, since Eve can send a fake message imitating Alice, as Eve too knows about Bob’s “public key”.

Figure 9— Public Key and Private Key, Usage

We can do a double encryption-decryption to prevent problems in both scenarios (see Figure 10).

Figure 10— Double Encryption/Decryption

Figure 11 — How HTTPS Works

In Figure 9, if Alice is the sender and Bob is the receiver; Alice can encrypt her message (i.e. “plaintext”) from her “private key”, then encrypt the resulting “ciphertext” from Bob’s “public key”. On the receiving end Bob can decrypt the received “ciphertext” with his “private key”, followed by decrypting the result further with Alice’s “public key”. In this case Eve will be unable to view the message as well as wouldn’t be able to send a fake message imitating Alice. Why? Because, Eve neither knows Alice’s “private key” nor Bob’s “private key”.

Doing a double-encryption all the time reduces performance as asymmetric encryption/ decryption is a computationally intensive operation. Hence most of the secure communication implementations nowadays, initially exchange a “temporary session-based common secret key” for a single communication “session” with asymmetric key encryption. Then this initial temporary session-based common encryption key is used for rest of the communication during the session with symmetric encryption.

Figure 11 illustrates the workflow followed during initiating an HTTPS client session by a web browser. Note that initially, a “temporary session-based symmetric encryption key” is exchanged by using asymmetric encryption algorithms. Then the less computational symmetric encryption takes place with the temporary symmetric session key.

Digital Signatures

We all have signed documents with pen and paper. But how many times have we felt that;

1. Our signatures can be forged by someone else?
2. Or our original signatures can be annexed with different content rather than what we actually signed?

A “digital signature” is constructed based on cryptographic hash functions and asymmetric key cryptography, providing permanent solutions to both of the above problems.

Figure 12 — Digital Signatures; Signing and Verification

Going back to the Alice and Bob scenario (see Figure 9), if Alice wants to sign a document and send to Bob;

1. First, Alice will have to create a “cryptographic hash” (e.g. MD5) based on all content of the document (i.e. “plaintext”) she wishes to sign.
2. Alice will encrypt the “hash” from step 1 with her “private key”. This is what we call the “digital signature”.
3. Alice will attach this “digital signature” to the original document (which we call “digitally signed data”) and send it to Bob over the network.

At the receiving end Bob will do the verification (see also Figure 12 and Figure 9).

1. First, Bob will re-generate a “cryptographic hash” based on content of Alice’s document. Note that Alice and Bob must use the same cryptographic hash algorithm implementation (e.g. MD5).
2. Bob will decrypt the received “digital signature” using Alice’s “public key”.
3. Bob will compare the “decrypted hash” from Step 2, with the “hash” generated in Step 1.

If both “hash”es are equal in Step 3, then Bob is certain that (see also Figure 12 and Figure 9);

1. The document was originally signed by Alice (since Bob decrypted the digital signature with Alice’s “public key” and only Alice knows about her “private key”)
2. Neither Alice nor any intruder in the network (like Eve) altered the document by any means after signing it, since the “hash” generated by Bob got tallied with the “hash” decrypted from the “digital signature”.

De-centralized Network

Figure 13 — Centralized Vs De-centralized Network

Figure 13, compares and contrasts a centralized and a de-centralized network.

An example of a “centralized network” is your online banking website. Your bank “dictates the truth”, and only expose related information to you, as the customer. All customers assume what their bank says is true made upon the longterm trust of the banking brand. “Priveleged users” such as your bank manager has the authority to view all transactions (i.e. “centralized bank ledger”) happening in the bank, dictate your interest rates & credit card fees etc.

An example of a “de-centralized network” is social media (e.g. Facebook, Instagram). Posts initiated by social media consumers are “not dictated” by any “core authority”. Every social media consumer (i.e. “every participant”) can access all posts submitted by him/her and all other participants (i.e. a “distributed ledger of social media posts”). So if there are 2 contradicting posts getting published and shared within the social media network how do you find out which one is true? Well, by looking at the responses to each post and picking up the post appreciated by the majority (i.e. the argument accepted by more than 50%).

Putting It All Together

Figure 14 — A preamble to Blockchain

Figure 14, provides a preamble to “blockchain technology”, for the ones who are curious about it. “Blockchain” is a set of tools that can be used to implement a “distributed ledger”, that could be “de-centrally verified” and “de-centrally computed”. So how can we make sure that everyone stays consistent and non-fraudulent within a “de-centrally ledgered network”? That is why we need “cryptographic hash function”s and “digital signature”s.

Finally, congratulations! on completing all pre-requisites required to understand the “blockchain technology”. Having reached this point, you will be in a better position to understand how the internals of blockchain works and its applications.

Interested in taking that initial step on transforming your supply chain or banking network by applying blockchain? Contact Us.