Skip to content

Commit

Permalink
Crypto Content Review (#3)
Browse files Browse the repository at this point in the history
* Content Review (In-progress)

* Update README.md

* Update hash.md

* Update hash-structures.md

* Update signatures.md

* Update signatures.md

* Update hash-structures.md

* Update signatures.md
  • Loading branch information
DrW3RK authored Apr 12, 2024
1 parent a6a8666 commit f2c1f71
Show file tree
Hide file tree
Showing 5 changed files with 14 additions and 15 deletions.
2 changes: 1 addition & 1 deletion README.md
Original file line number Diff line number Diff line change
Expand Up @@ -49,7 +49,7 @@ In the second day, we will move our focus over to the Polkadot ecosystem, and bu

There are many great resources available for learning about Blockchains, Rust, and Polkadot.

Many of those resources was used directly and indirectly in the creation of this site.
Many of those resources were used directly and indirectly in creating this site.

Check out these additional resources if you want to extend or reinforce what you have learned here:

Expand Down
2 changes: 1 addition & 1 deletion pre-rust/crypto/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -13,4 +13,4 @@ Instead, this content is intended to introduce concepts in cryptography which ar

We will not attempt to explain HOW these different primitives work, but instead just explain the properties of these primitives and how these properties can be used to achieve our desired outcomes.

There are more crypto topics that could be covered to get a deeper understanding of blockchains, but consider this the minimal baseline knowledge needed for this workshop.
More crypto topics could be covered to understand blockchains better, but consider this the minimal baseline knowledge needed for this workshop.
14 changes: 7 additions & 7 deletions pre-rust/crypto/hash-structures.md
Original file line number Diff line number Diff line change
Expand Up @@ -21,7 +21,7 @@ This structure is similar to the structure of a linked list, but with a few uniq

1. The structure can only be formed from start to finish.

You are not able to build new nodes on the hash chain anywhere but the end of the chain. Again, because the nodes are affected by the hash of the previous node, inserting a new node anywhere would completely change the data in all subsequent nodes.
You cannot build new nodes on the hash chain anywhere but at the end of the chain. Again, because the nodes are affected by the hash of the previous node, inserting a new node anywhere else would completely change the data and their corresponding hashes in all subsequent nodes.


## Merkle Tree
Expand Down Expand Up @@ -51,24 +51,24 @@ At the end of the merkle trie process, you end up with a single hash that unique
This is called the merkle root.

You can use the merkle root to quickly compare that two individuals have exactly the same data and structure without having to share all the data itself.
Due to the properties of hashes, if you and I both have a merkle tree with the same merkle root, we know that we must both have all of the children data which uniquely generate that hash.
This scales to any amount of data since the final merkle root is always the same fixed size.
Due to the properties of hashes, if you and I have a merkle tree with the same merkle root, we can be sure that we both have the same children data, which uniquely generates that root hash.
This scales to any amount of data since the final merkle root is always of the same fixed size.

### Merkle Proofs

Using the merkle tree structure, we are able to identify the existence of a specific piece of data exists in the tree without needing all of the data.
Using the merkle tree structure, we can prove the existence of a specific piece of data in the tree without needing all of the data.

Let's say for example I have a merkle tree which is identifiable by its unique merkle root hash.
In that merkle tree, I want to prove to you there is node with the message "Hello, World!".
The naive approach would be to give you all data which is stored in the tree, where you can plainly see "Hello, World!", and let you calculate the whole structure yourself.
However, since the structure uses recursive hashes, whose output cannot be easily controlled, I can provide the same assurance with just a subset of data.
However, since the structure uses recursive hashing, whose output cannot be easily controlled, I can provide the same assurance with just a subset of data.

![Merkle Proof](./assets/Merkle-Copaths.png ':size=500')

Instead of giving you all the data, imagine I just give you the data of the nodes leading to the specific data I want to prove exists.
Data which is not relevant to you can be represented just by their hash.
Then, with those hashes, and all the relevant nodes leading to the data you are interested in, you are able to verify that this structure contains that data.

To re-emphasize, this is possible because it is assumed that it would be nearly impossible for me to construct a hash which matches my merkle root while making up data in order to trick you into thinking the tree has some data it does not. The output of a hash is random, and finding some data which would work, especially one that is coherent to my claims, would be impractical.
To re-emphasize, this is possible because it would be nearly impossible for me to construct a hash that matches my merkle root while manipulating or making up the underlying data. Hence, it is impossible to trick you into thinking the tree has some data it does not. The output of a hash is random, and finding some data which would work, especially one that is coherent to my claims, would be impractical.

Merkle proof reduce the amount of data needed to prove the existence of data from `O(N)` to `O(log N)`.
Merkle proof reduces the amount of data needed to prove the existence of data from `O(N)` to `O(log N)`. If you are familiar with the concepts of computability and complexity, you would really appreciated this performance improvement!
4 changes: 2 additions & 2 deletions pre-rust/crypto/hash.md
Original file line number Diff line number Diff line change
Expand Up @@ -43,9 +43,9 @@ There is a subset of hash functions which are called "cryptographic hash functio
- Collision resistance (attacker controls both inputs)
- It should be difficult to find two different messages `m1` and `m2` such that `hash(m1) = hash(m2)`.
- Such a pair is called a cryptographic hash collision.
- This property is sometimes referred to as strong collision resistance. It requires a hash value at least twice as long as that required for pre-image resistance; otherwise collisions may be found by a birthday attack.
- This property is sometimes referred to as strong collision resistance. It requires a hash value at least twice as long as that required for pre-image resistance; otherwise collisions may be found by a [birthday attack](https://en.wikipedia.org/wiki/Birthday_attack).

An example of a cryptographic hash function is Blake2_256.
An example of a cryptographic hash function is [Blake2_256](https://en.wikipedia.org/wiki/BLAKE_(hash_function)), which takes a binary input of an arbitrary size and outputs 256 bits.

Learn more at: https://en.wikipedia.org/wiki/Cryptographic_hash_function

Expand Down
7 changes: 3 additions & 4 deletions pre-rust/crypto/signatures.md
Original file line number Diff line number Diff line change
Expand Up @@ -48,12 +48,11 @@ Digital signatures offer several essential properties:

## Replay Attacks

Replay attacks occur when someone intercepts and resends a valid message.
The receiver will carry out the instructions since the message contains a valid signature.
In the digital world, we have to assume that all channels are insecure, and all messages should be considered intercepted.

We assume that all channels are insecure, and that all messages should be considered intercepted.
Replay attacks can occur when someone intercepts and resends a copy of a valid message. The receiver may carry out the instructions since the message contains a valid signature, especially in an automated setup (like in many digital applications). An example scenario would be to cash in a check at a bank multiple times by presenting multiple copies of the original check with the authentic signature. Of course, the banks use various mechanisms to avoid this scenario.

To prevent replay attacks, signing payloads should be designed so that they can only be used one time and in one context.
To prevent replay attacks, signing digital payloads should be designed so that they can only be used one time and in one context.

For example using:

Expand Down

0 comments on commit f2c1f71

Please sign in to comment.