Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

brushingup crypto slides #30

Open
wants to merge 5 commits into
base: main
Choose a base branch
from
Open

brushingup crypto slides #30

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
f25e6f1
updating slides
coax1d Dec 11, 2023
7e6b3ce
cleaning up hashing slides
coax1d Dec 12, 2023
1bc5182
basic signatures slide updates
coax1d Dec 14, 2023
bd56ae9
cleanup hash based ds
coax1d Dec 14, 2023
6254e8e
Update content/cryptography/addresses/slides.md
coax1d Dec 19, 2023
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
21 changes: 17 additions & 4 deletions content/cryptography/addresses/slides.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -57,6 +57,8 @@ Notes:

It turns out that converting from hex/base64 to base58 can in theory take n^2 time!

The number of bits of a character is log2(Base) so for base58 it is log2(58) ~ 5.8

---

# Mnemonics and Seed Creation
Expand Down Expand Up @@ -114,18 +116,19 @@ _The first 5 words of the [BIP39 English dictionary](https://github.com/bitcoin/

## Mnemonic to Secret Key

Of course, the secret key is a point on an elliptic curve, not a phrase.

BIP39 applies 2,048 rounds of the SHA-512 hash function<br />to the mnemonic to derive a 64 byte key.
The secret key is a scalar value from the scalar field of the base field which the elliptic curve is defined over. Not a phrase.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is probably too detailed for the level of math the cryptography module should talk about, and the number of words and terms will just make people confused.

Probably better to phrase it as either "a 64-byte value" (which is a bit imprecise, but more black-boxy) or "a mathematical construct specific to the cryptography you're using" (which is broadly accurate, and doesn't necessitate readers to try to figure out what a "scalar value", "scalar field", or "base field" are.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am correcting the incorrect statement which was made that a secret key is a point on an elliptic curve which is just a false statement. If math is going to be talked about it should atleast be correct.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A secret key is not a curve point

Copy link
Author

@coax1d coax1d Dec 19, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead we can just not reference any elliptic curve. But to be honest we are going to introduce a ZK section some small references to curves and fields isnt that bad. There isnt even a single actual math line in here I kind of disagree that it is too much math. I am not showing the scalar field times the base field element or something.

It is also important to note that there will be founders in crypto which probably wont understand half of it either so I think we are going to just have to wing it with what we choose to let some people scratch their head over.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree that we should be correct everywhere we do reference the math, and should for sure correct what's in here right now.

If you want to keep the definition as written, I'm fine with that if you add something in the notes for the lecturer to say that the definition is not important to know. My thought was that the definition written is a bit long and contains a few terms most won't know, and as people are learning most everything for the first time, it would be distracting.


Substrate uses the entropy byte array from the mnemonic.
BIP39 applies 2,048 rounds of the SHA-512 hash function<br /> to the mnemonic to derive a 64 byte key.

---

## Portability

Different key derivation functions affect the ability to use the same mnemonic in multiple wallets as different wallets may use different functions to derive the secret from the mnemonic.

Notes:
i.e. May hash to a different base field because of a different elliptic curve
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In here you can put the details previously added to the slide, saying that in ECC a secret key is actually a scalar value from the scalar field of the base field which the elliptic curve is defined over.


---

## Cryptography Types
Expand All @@ -140,7 +143,14 @@ We will go more in depth in future lectures!

Notes:

These are digital signature schemes. ECDSA can use any elliptic curve but
in the case of bitcoin it use secp256k1

Sr25519 and Ed25519 uses the same which is Curve25519

You may have learned RSA in school. It is outdated now, and requires _huge_ keys.
RSA-4096: A 4096-bit RSA key is 512 bytes
sr25519 is 32 bytes

---

Expand All @@ -150,6 +160,9 @@ An address is a representation of a public key, potentially with additional cont

Notes:

A public key is a point on a defined elliptic curve more specifically
the secret scalar value multiplied times a fixed base point on some curve G

Having an address for a symmetric cryptography doesn't actually make any sense, because there is no
public information about a symmetric key.

Expand Down
55 changes: 33 additions & 22 deletions content/cryptography/basic-signatures/slides.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -12,10 +12,12 @@ duration: 1 hour

Signature libraries should generally all expose some basic functions:

- `fn generate_key(r) -> sk;` <br /> Generate a `sk` (secret key) from some input `r`.
- `fn public_key(sk) -> pk;` <br /> Return the `pk` (public key) from a `sk`.
- `fn sign(sk, msg) -> signature;` <br /> Takes `sk` and a message; returns a digital signature.
- `fn verify(pk, msg, signature) -> bool;` <br /> For the inputs `pk`, a message, and a signature; returns whether the signature is valid.
<ul>
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All this stuff doesn't even render for me.

What's the reasoning for making this as inline HTML instead of just keeping it as markdown? I don't see anything in here that isn't supported in markdown (unordered lists, code).

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It renders for me. But it already got pushed in the pba-content repo. Idk half of the slides in all modules is HTML or MD so it is a mix. There really hasnt been any enforcement. Also the MD cant be limiting sometimes it doesnt cover everything. If its really a big deal it can be changed. It wouldnt take long.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, weird that it doesn't render for me locally but does otherwise

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Glad to see the book getting some love 🌠 wishing the team for HK all the best 🙏 - hope to see the work for that wave end up translating here. I am not in the game for it (at least for now) but have some advice/notes if you wanna hear em 😁

Idk half of the slides in all modules is HTML or MD so it is a mix.

Ultimately not up to me anymore, though I tried to enforce MD. I did work with you @coax1d directly on this before in case you forgot 😝 🫶 - you even helped convert a subset of your HTML to MD where possible before too. I did intentionally archive the (private) pba-content repo that is not AFAIK up to date with the fair bit of polish I put in post UCB that is now in the initial publishing of this book that included moving HTML to MD where possible. I highly suggest pulling content from this repo before making changes to the what IMHO should remain archived older repo.

For some background, the chief motivator for using the reveal-md tooling for us from the beginning was:

Focus on content. Don't mess with style. You do not need to know anything but simple MD to make slides. Where MD is insufficiently expressive, there are minimal custom HTML slide style elements to get that content crafted and delivered, with easy templates/examples in https://github.com/Polkadot-Blockchain-Academy/pba-book/tree/main/content/contribute/copy-paste-slides.

Maintainability and uniformity. The book has a large number of contributors with zero up to expert HTML/CSS experience, and the next faculty to take on teaching may be anywhere in that range. It's much more sustainable to have as simple and clean content for everyone to reasonable in the long term, and much more portable (like in the pure reveal-md tooling -> to this book).

Maybe @Asamartino wants to do something different now, and that driving factor isn't as important now. 🤷 Happy to help outline and implement a strategy with maintainers here that lands in the contributor's guide, if the PBA team wants this.

For the rendering, sadly as it stands there are at least four different HTML servers depending on what commands you run (reveal has dev and build, bun with a minimal static server, and mdbook has a watching one). This could be cleaned up for a better overall UX, IMHO this would fork or replace the reveal-md tooling with something minimal here, and as I moved to bun for the book's static server here, I would opt for better configure mdbook (perhaps a custom plugin) as a tool to get slides -> reveal HTML -> full book.

Maybe related: webpro/reveal-md#433 but it's been a while since I played with different behavior.

In the end, the source of truth on what things will render as should be assessed via running markers or makers serve -> https://github.com/Polkadot-Blockchain-Academy/pba-book/blob/main/Makefile.toml#L108-L125 as this is what actually gets deployed to github pages.

<li class="fragment"><code>fn generate_key(r) -> sk;</code> <br />Generate a <code>sk</code> (secret key) from some input <code>r</code>.</li>
<li class="fragment"><code>fn public_key(sk) -> pk;</code> <br /> Return the <code>pk</code> (public key) from a <code>sk</code>.</li>
<li class="fragment"><code>fn sign(sk, msg) -> signature;</code> <br /> Takes <code>sk</code> and a message; returns a digital signature.</li>
<li class="fragment"><code>fn verify(pk, msg, signature) -> bool;</code> <br /> For the inputs <code>pk</code>, a message, and a signature; returns whether the signature is valid.</li>
</ul>

Notes:

Expand Down Expand Up @@ -72,10 +74,12 @@ This means the verifier will need to run the correct hash function on the messag

Signatures provide many useful properties:

- Confidentiality: Weak, the same as a hash
- Authenticity: Yes
- Integrity: Yes
- Non-repudiation: Yes
<ul>
<li class="fragment"><strong>Confidentiality: </strong> Weak, the same as a hash</li>
<li class="fragment"><strong>Authenticity: </strong> Yes</li>
<li class="fragment"><strong>Integrity: </strong> Yes</li>
<li class="fragment"><strong>Non-repudiation: </strong> Yes</li>
</ul>

Notes:

Expand All @@ -85,10 +89,11 @@ If a hash is signed, you can prove a signature is valid _without_ telling anyone

## Signing Payloads

Signing payloads are an important part of system design.<br />
Users should have credible expectations about how their messages are used.

For example, when a user authorizes a transfer,<br />they almost always mean just one time.
<ul>
<li class="fragment">Signing payloads are an important part of system design.</li>
<li class="fragment">Users should have credible expectations about how their messages are used.</li>
<li class="fragment">For example, when a user authorizes a transfer, they almost always mean just one time.</li>
</ul>

Notes:

Expand Down Expand Up @@ -135,9 +140,11 @@ Examples:

<pba-flex center>

- Monotonically increasing account nonces
- Timestamps (or previous blocks)
- Context identifiers like genesis hash and spec versions
<ul>
<li class="fragment">Monotonically increasing account nonces</li>
<li class="fragment">Timestamps (or previous blocks)</li>
<li class="fragment">Context identifiers like genesis hash and spec versions</li>
</ul>

---

Expand All @@ -147,18 +154,22 @@ Examples:

## ECDSA

- Uses Secp256k1 elliptic curve.
- ECDSA (used initially in Bitcoin/Ethereum) was developed to work around the patent on Schnorr signatures.
- ECDSA complicates more advanced cryptographic techniques, like threshold signatures.
- Nondeterministic
<ul>
<li class="fragment">Commonly uses Secp256k1 elliptic curve.</li>
<li class="fragment">ECDSA (used initially in Bitcoin/Ethereum) was developed to work around the patent on Schnorr signatures.</li>
<li class="fragment">ECDSA complicates more advanced cryptographic techniques, like threshold signatures.</li>
<li class="fragment">Non-Deterministic</li>
</ul>

---

## Ed25519

- Schnorr signature designed to reduce mistakes in implementation and usage in classical applications, like TLS certificates.
- Signing is 20-30x faster than ECDSA signatures.
- Deterministic
<ul>
<li class="fragment">Schnorr signature designed to reduce mistakes in implementation and usage in classical applications, like TLS certificates.</li>
<li class="fragment">Signing is 20-30x faster than ECDSA signatures.</li>
<li class="fragment">Deterministic</li>
</ul>

---

Expand Down
13 changes: 5 additions & 8 deletions content/cryptography/hash-based-data-structures/slides.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -34,18 +34,15 @@ Each block has the hash of the previous one.

A binary Merkle tree is a binary tree using hashes to connect nodes.

Notes:

Ralph Merkle is a Berkeley alum!

---

## Proofs

- The root or head hash is a commitment to the entire data structure.
- Generate a proof by expanding some but not all hashes.

_Crucial for the trustless nature of decentralised cryptographic data systems!_
<ul>
<li class="fragment">The root or head hash is a commitment to the entire data structure.</li>
<li class="fragment">Generate a proof by expanding some but not all hashes.</li>
<li class="fragment"><i>Crucial for the trustless nature of decentralised cryptographic data systems!</i></li>
</ul>

---

Expand Down
23 changes: 14 additions & 9 deletions content/cryptography/hashes/slides.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -20,12 +20,15 @@ We often want a succinct representation of some data<br />with the expectation t

<pba-flex center>

1. Accept unbounded size input
1. Map to a bounded output
1. Be fast to compute
1. Be computable strictly one-way<br />(difficult to find a pre-image for a hash)
1. Resist pre-image attacks<br />(attacker controls one input)
1. Resist collisions<br />(attacker controls both inputs)
<section>
<p class="fragment">Accept unbounded size input</p>
<p class="fragment">Map to a bounded output</p>
<p class="fragment">Be fast to compute</p>
<p class="fragment">Be computable strictly one-way<br />(difficult to find a pre-image for a hash)</p>
<p class="fragment">Resist pre-image attacks<br />(attacker controls one input)</p>
<p class="fragment">Second pre-image resistance: Given an input and output<br />(resisting second pre-image attacks).</p>
<p class="fragment">Resist collisions<br />(attacker controls both inputs)</p>
</section>

</pba-flex>

Expand Down Expand Up @@ -266,9 +269,11 @@ e.g., a 256 bit hash output yields 2^128 security

It should be difficult for someone to partially (for a substring of the hash output) find a collision or "second" pre-image.

- Bitcoin PoW is a partial pre-image attack.
- Prefix/suffix pre-image attack resistance reduces opportunity for UI attacks for address spoofing.
- Prefix collision resistance important to rationalize costs for some cryptographic data structures.
<section>
<p class="fragment">Bitcoin PoW is a partial pre-image attack.</p>
<p class="fragment">Prefix/suffix pre-image attack resistance reduces opportunity for UI attacks for address spoofing.</p>
<p class="fragment">Prefix collision resistance important to rationalize costs for some cryptographic data structures.</p>
</section>

---

Expand Down
Loading