Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 5 additions & 5 deletions chapters/chapter-02-cryptography.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -8,9 +8,9 @@ Cryptography is a fundamental building block of blockchain systems, DLTs, smart

=== Hashing functions

Early in computing history, it became evident that messages between digital systems can change during transmission due to issues with the communication medium or other reasons. A solution to this problem became pressing. An initial solution involved adding an extra parity bit to the data sent between devices, serving as a safety guarantee to check whether the data had changed.
Early in computing history, it became evident that messages between digital systems can change during transmission due to issues with the communication medium or other reasons. Solving this problem became pressing. An initial solution involved adding an extra parity bit to the data sent between devices, serving as a safety guarantee to check whether the data had changed.

A computer bit can either be 0 or 1. For a naive implementation of a parity bit, if the total number of bits set to 1 in a data packet is odd, then the parity bit is set to 1; if even, it is set to 0. However, since the parity bit can only store a single 0 or 1, there is a high chance that errors could occur undetected. For example, if two bits that were originally 0s were altered to 1s, the naive parity bit would still appear valid. Although better parity schemes exist, they remain insufficient for the large amounts of data being transmitted.
A computer bit can either be 0 or 1. For a naive implementation of a parity bit, if the total number of bits set to 1 in a data packet is odd, then the parity bit is set to 1; if even, it is set to 0. However, since the parity bit can only store a single 0 or 1, there is a high chance that errors could occur undetected. For example, if two bits that were originally zeroes were altered to ones, the naive parity bit would still appear valid. Although better parity schemes exist, they remain insufficient for the large amounts of data being transmitted.

Building on this concept, checksums(((checksum))) were introduced. Unlike parity bits, which encode sanity check information into a single bit, checksums use larger data sizes for encoding such checks, ranging from single to multiple bytes.

Expand Down Expand Up @@ -69,7 +69,7 @@ image::symmetricenc.png[]

The steps involved in the process are as follows:

* Step 0 typically occurs before the parties communicate over the medium used to transmit encrypted data. The parties must agree on a shared encryption(((encryption)))/decryption key, which will be used for both encryption and decryption. This key could be generated by Party A, Party B, or even generated together — it does not matter as long as both parties have access to the same shared key. It is important to note that any party possessing the specific key can both decrypt and encrypt messages.
* Step 0 typically occurs before the parties communicate over the medium used to transmit encrypted data. The parties must agree on a shared encryption(((encryption)))/decryption key, which will be used for both purposes. This key could be generated by Party A, Party B, or even generated together. It does not matter as long as both parties have access to the same shared key. It is important to note that any party possessing the specific key can both decrypt and encrypt messages.

* Once the sending party (in this case, Party A) has the key, they can encrypt the data intended for the other party by applying the symmetric encryption algorithm using the key, as depicted in step 1. The algorithm will output the encrypted data.

Expand All @@ -93,7 +93,7 @@ The introduction of _asymmetric encryption_ in the 1970s provided a more secure

- A _private key_ that the recipient keeps confidential. This private key(((private key))) is used to decrypt messages encrypted with their public key(((public key))).

The public and private keys are intimately linked (hence the term key pair(((key pair))) ), and it is impossible footnote:[or rather computationally infeasible] to derive the private key from the public key.
The public and private keys are intimately linked (hence the term _key pair_(((key pair))) ), and it is impossible footnote:[or rather computationally infeasible] to derive the private key from the public key.

[caption="Figure {counter:figure}. ", reftext="Figure {figure}"]
.An overview of typical communication using asymmetric encryption.
Expand All @@ -112,7 +112,7 @@ image::asymmetricenc.png[]

Asymmetric encryption does not allow Party B to send messages back to Party A using the same encryption/decryption key. This ensures that messages intended for a specific party can only be decrypted by that party. To reply, Party B simply uses Party A's public key to encrypt messages.

While asymmetric encryption(((asymmetric encryption))) ensures that only the intended recipient can decrypt a particular message, it does not prevent a sender from impersonating someone else. This also applies to symmetric key encryption when the shared encryption/decryption key is compromised. For instance, consider a malicious actor, Party C, who has access to Party B's public key(((public key))). Party C could encrypt messages intended for Party B and send them, falsely claiming to be Party A. Party B would have no means to identify that the messages are actually from Party C. The solution to this issue is _digital signatures_, which will be discussed next.
While asymmetric encryption(((asymmetric encryption))) ensures that only the intended recipient can decrypt a particular message, it does not prevent a sender from impersonating someone else. This also applies to symmetric key encryption when the shared encryption/decryption key is compromised. For instance, consider a malicious actor, Party C, who has access to Party B's public key(((public key))). Party C could encrypt messages intended for Party B and send them, falsely claiming to be Party A. Party B would have no means to identify that the messages are actually from Party C. The solution to this issue is _digital signatures_, which are discussed next.

=== Digital signatures

Expand Down