[PUBLISHER] upload files #159

* PUSH NOTE : 09. Transport Layer Security.md

* PUSH ATTACHMENT : is-09-tls-handshake.png

* PUSH NOTE : 08. Public Key Infrastructure.md

* PUSH ATTACHMENT : is-08-certificate-validation.png

* PUSH NOTE : 07. Public Key Cryptography.md

* PUSH NOTE : 06. RSA and ElGamal Encryption.md

* PUSH NOTE : 05. Modular Arithmetic (2).md

* PUSH NOTE : 04. Modular Arithmetic (1).md

* PUSH NOTE : 03. Symmetric Key Cryptography (2).md

* PUSH ATTACHMENT : is-03-feistel-function.png

* PUSH ATTACHMENT : is-03-ecb-encryption.png

* PUSH ATTACHMENT : is-03-cbc-encryption.png

* PUSH ATTACHMENT : is-03-cfb-encryption.png

* PUSH ATTACHMENT : is-03-ofb-encryption.png

* PUSH ATTACHMENT : is-03-ctr-encryption.png

* PUSH NOTE : 02. Symmetric Key Cryptography (1).md

* PUSH NOTE : 01. Security Introduction.md

* PUSH ATTACHMENT : is-01-cryptosystem.png

* PUSH NOTE : 9. Public Key Encryption.md

* PUSH ATTACHMENT : mc-09-ss-pke.png

* PUSH NOTE : 7. Key Exchange.md

* PUSH ATTACHMENT : mc-07-dhke.png

* PUSH ATTACHMENT : mc-07-dhke-mitm.png

* PUSH ATTACHMENT : mc-07-merkle-puzzles.png

* PUSH NOTE : 6. Hash Functions.md

* PUSH ATTACHMENT : mc-06-merkle-damgard.png

* PUSH ATTACHMENT : mc-06-davies-meyer.png

* PUSH ATTACHMENT : mc-06-hmac.png

* PUSH NOTE : 5. CCA-Security and Authenticated Encryption.md

* PUSH ATTACHMENT : mc-05-ci.png

* PUSH ATTACHMENT : mc-05-etm-mte.png

* PUSH NOTE : 4. Message Authentication Codes.md

* PUSH ATTACHMENT : mc-04-mac.png

* PUSH ATTACHMENT : mc-04-mac-security.png

* PUSH ATTACHMENT : mc-04-cbc-mac.png

* PUSH ATTACHMENT : mc-04-ecbc-mac.png

* PUSH NOTE : 2. PRFs, PRPs and Block Ciphers.md

* PUSH ATTACHMENT : mc-02-block-cipher.png

* PUSH ATTACHMENT : mc-02-feistel-network.png

* PUSH ATTACHMENT : mc-02-des-round.png

* PUSH ATTACHMENT : mc-02-DES.png

* PUSH ATTACHMENT : mc-02-aes-128.png

* PUSH ATTACHMENT : mc-02-2des-mitm.png

* PUSH NOTE : 16. The GMW Protocol.md

* PUSH ATTACHMENT : mc-16-beaver-triple.png

* PUSH NOTE : 13. Sigma Protocols.md

* PUSH ATTACHMENT : mc-13-sigma-protocol.png

* PUSH ATTACHMENT : mc-10-schnorr-identification.png

* PUSH ATTACHMENT : mc-13-okamoto.png

* PUSH ATTACHMENT : mc-13-chaum-pedersen.png

* PUSH ATTACHMENT : mc-13-gq-protocol.png

* PUSH NOTE : 12. Zero-Knowledge Proofs (Introduction).md

* PUSH ATTACHMENT : mc-12-id-protocol.png

* PUSH NOTE : 10. Digital Signatures.md

* PUSH ATTACHMENT : mc-10-dsig-security.png

* PUSH NOTE : 1. OTP, Stream Ciphers and PRGs.md

* PUSH ATTACHMENT : mc-01-prg-game.png

* PUSH ATTACHMENT : mc-01-ss.png

* DELETE FILE : _posts/Lecture Notes/Internet Security/2023-09-10-security-intro.md

* DELETE FILE : _posts/Lecture Notes/Internet Security/2023-09-11-symmetric-key-cryptography-1.md

* DELETE FILE : _posts/Lecture Notes/Internet Security/2023-09-18-symmetric-key-cryptography-2.md

* DELETE FILE : _posts/Lecture Notes/Internet Security/2023-09-25-modular-arithmetic-1.md

* DELETE FILE : _posts/Lecture Notes/Internet Security/2023-10-04-modular-arithmetic-2.md

* DELETE FILE : _posts/Lecture Notes/Internet Security/2023-10-04-rsa-elgamal.md

* DELETE FILE : _posts/Lecture Notes/Internet Security/2023-10-09-public-key-cryptography.md

* DELETE FILE : _posts/Lecture Notes/Internet Security/2023-10-16-pki.md

* DELETE FILE : _posts/Lecture Notes/Internet Security/2023-10-18-tls.md

* DELETE FILE : _posts/lecture-notes/internet-security/2023-10-19-public-key-encryption.md

* DELETE FILE : assets/img/posts/Lecture Notes/Internet Security/is-01-cryptosystem.png

* DELETE FILE : assets/img/posts/Lecture Notes/Internet Security/is-03-cbc-encryption.png

* DELETE FILE : assets/img/posts/Lecture Notes/Internet Security/is-03-cfb-encryption.png

* DELETE FILE : assets/img/posts/Lecture Notes/Internet Security/is-03-ctr-encryption.png

* DELETE FILE : assets/img/posts/Lecture Notes/Internet Security/is-03-ecb-encryption.png

* DELETE FILE : assets/img/posts/Lecture Notes/Internet Security/is-03-feistel-function.png

* DELETE FILE : assets/img/posts/Lecture Notes/Internet Security/is-03-ofb-encryption.png

* DELETE FILE : assets/img/posts/Lecture Notes/Internet Security/is-08-certificate-validation.png

* DELETE FILE : assets/img/posts/Lecture Notes/Internet Security/is-09-tls-handshake.png

* DELETE FILE : assets/img/posts/Lecture Notes/Modern Cryptography/mc-01-prg-game.png

* DELETE FILE : assets/img/posts/Lecture Notes/Modern Cryptography/mc-01-ss.png

* DELETE FILE : assets/img/posts/Lecture Notes/Modern Cryptography/mc-02-2des-mitm.png

* DELETE FILE : assets/img/posts/Lecture Notes/Modern Cryptography/mc-02-DES.png

* DELETE FILE : assets/img/posts/Lecture Notes/Modern Cryptography/mc-02-aes-128.png

* DELETE FILE : assets/img/posts/Lecture Notes/Modern Cryptography/mc-02-block-cipher.png

* DELETE FILE : assets/img/posts/Lecture Notes/Modern Cryptography/mc-02-des-round.png

* DELETE FILE : assets/img/posts/Lecture Notes/Modern Cryptography/mc-02-feistel-network.png

* DELETE FILE : assets/img/posts/Lecture Notes/Modern Cryptography/mc-04-cbc-mac.png

* DELETE FILE : assets/img/posts/Lecture Notes/Modern Cryptography/mc-04-ecbc-mac.png

* DELETE FILE : assets/img/posts/Lecture Notes/Modern Cryptography/mc-04-mac-security.png

* DELETE FILE : assets/img/posts/Lecture Notes/Modern Cryptography/mc-04-mac.png

* DELETE FILE : assets/img/posts/Lecture Notes/Modern Cryptography/mc-05-ci.png

* DELETE FILE : assets/img/posts/Lecture Notes/Modern Cryptography/mc-05-etm-mte.png

* DELETE FILE : assets/img/posts/Lecture Notes/Modern Cryptography/mc-06-davies-meyer.png

* DELETE FILE : assets/img/posts/Lecture Notes/Modern Cryptography/mc-06-hmac.png

* DELETE FILE : assets/img/posts/Lecture Notes/Modern Cryptography/mc-06-merkle-damgard.png

* DELETE FILE : assets/img/posts/Lecture Notes/Modern Cryptography/mc-07-dhke-mitm.png

* DELETE FILE : assets/img/posts/Lecture Notes/Modern Cryptography/mc-07-dhke.png

* DELETE FILE : assets/img/posts/Lecture Notes/Modern Cryptography/mc-07-merkle-puzzles.png

* DELETE FILE : assets/img/posts/Lecture Notes/Modern Cryptography/mc-09-ss-pke.png

* DELETE FILE : assets/img/posts/Lecture Notes/Modern Cryptography/mc-10-dsig-security.png

* DELETE FILE : assets/img/posts/Lecture Notes/Modern Cryptography/mc-10-schnorr-identification.png

* DELETE FILE : assets/img/posts/Lecture Notes/Modern Cryptography/mc-12-id-protocol.png

* DELETE FILE : assets/img/posts/Lecture Notes/Modern Cryptography/mc-13-chaum-pedersen.png

* DELETE FILE : assets/img/posts/Lecture Notes/Modern Cryptography/mc-13-gq-protocol.png

* DELETE FILE : assets/img/posts/Lecture Notes/Modern Cryptography/mc-13-okamoto.png

* DELETE FILE : assets/img/posts/Lecture Notes/Modern Cryptography/mc-13-sigma-protocol.png

* DELETE FILE : assets/img/posts/Lecture Notes/Modern Cryptography/mc-16-beaver-triple.png

_posts/Lecture Notes/Internet Security/2023-10-18-tls.md

@@ -1,333 +0,0 @@
----
-share: true
-toc: true
-math: true
-categories:
-  - Lecture Notes
-  - Internet Security
-tags:
-  - lecture-note
-  - security
-title: 09. Transport Layer Security
-date: 2023-10-18
-github_title: 2023-10-18-tls
-image:
-  path: /assets/img/posts/Lecture Notes/Internet Security/is-09-tls-handshake.png
-attachment: 
-  folder: assets/img/posts/Lecture Notes/Internet Security
----
-
-This is a brief comparison of HTTP and HTTPS
-
-- HTTP: HyperText Transfer Protocol
-- HTTPS: HyperText Transfer Protocol **Secure**
-	- Uses certificates, encryption, TLS.
-	- Used for privacy.
-
-## TLS Overview
-
-**Transport Layer Security** (TLS) **protocol** provides privacy (confidentiality) and data integrity between two communicating parties.
-
-- TLS is built on top of TCP/IP.
-- TLS is based on **secure socket layer** (SSL), but now SSL is deprecated.
-
-You can check if TLS is used on your browser. The address should begin with `https` and there should be a green lock icon.
-
-### TLS History
-
-- 1994: SSL 1.0
-	- Netscape (browser company) used it internally for their browser.
-	- Not publicly released.
-- 1995: SSL 2.0
-	- Published by Netscape.
-	- There were several weaknesses.
-- 1996: SSL 3.0
-	- Designed by Netscape and Paul Kocher.
-- 1999: TLS 1.0
-	- IETF makes RFC 2246 based on SSL 3.0.
-	- Not inter-operable with SSL 3.0
-		- TLS uses HMAC instead of MAC.
-		- TLS can run on any port.
-- 2006: TLS 1.1
-	- RFC 4346
-	- Protection against CBC padding attacks.
-- 2008: TLS 1.2
-	- RFC 5246
-	- More options in cipher suites like SHA256, AES.
-- 2018: TLS 1.3
-	- RFC 8446
-	- Insecure ciphers such as RC4, DES were removed.
-	- Streamline RTT handshakes. (0-RTT mode)
-
-## CBC Padding Oracle Attack
-
-Recall [CBC Mode (Internet Security)](../2023-09-18-symmetric-key-cryptography-2#cipher-block-chaining-mode-cbc) .
-
-Suppose that each block has $8$ bytes. If the message size is not a multiple of the block size, we pad the message. If we need to pad $b$ bytes, we pad $b$ bytes with $b$, encoded in binary.
-
-If the padding is not valid, the decryption algorithm outputs a *padding error* during the decryption process. The attacker can observe if a padding error has occurred, and use this information to recover the plaintext.
-
-To defend this attack, we can use [encrypt-then-MAC (Modern Cryptography)](../../modern-cryptography/2023-09-26-cca-security-authenticated-encryption#encrypt-then-mac-etm), or hide the padding error.
-
-### Attack in Detail
-
-We will perform a **chosen ciphertext attack** to fully recover the plaintext.
-
-Suppose that we obtains a ciphertext $(\mathrm{IV}, c_1, c_2)$, which is an encryption of two blocks $m = m_0 \parallel m_1$, including the padding. By the CBC encryption algorithm we know that
-
-$$
-c_1 = E_k(m_0 \oplus \mathrm{IV}), \qquad c_2 = E_k(m_1 \oplus c_1).
-$$
-
-We don't know exactly how many padding bits there were, but it doesn't matter. We brute force by **changing the last byte of $c_1$** and requesting the decryption of the modified ciphertext $(\mathrm{IV}, c_1', c_2)$.
-
-The decryption process of the last block is $c_1 \oplus D_k(c_2)$, so by changing the last byte of $c_1$, we hope to get a decryption result that ends with $\texttt{0x01}$. Then the last byte $\texttt{0x01}$ will be treated as a padding and padding errors will not occur. So we keep trying until we don't get a padding error.
-
-Now, suppose that we successfully changed the last byte of $c_1$ to $b$, so that the last byte of $(c_1[0\dots6] \parallel b) \oplus D_k(c_2)$ is $\texttt{0x01}$. Next, we change the second-last bit $c_1[6]$ and request the decryption and hope to get an output that ends with $\texttt{0x0202}$. The last two bytes will also be treated as a padding and we won't get a padding error.
-
-We repeat the above process until we get a modified ciphertext $c_1' \parallel c_2$, where the decryption result ends with $8$ bytes of $\texttt{0x08}$. Then now we know that
-
-$$
-c_1' \oplus D_k(c_2) = \texttt{0x08}^8.
-$$
-
-Then we can recover $D_k(c_2) = c_1' \oplus \texttt{0x08}^8$, and then since $m_1 = c_1 \oplus D_k(c_2)$,
-
-$$
-m_1 = c_1 \oplus D_k(c_2) = c_1 \oplus c_1' \oplus \texttt{0x08}^8,
-$$
-
-allowing us to recover the whole message $m_1$.
-
-Now to recover $m_0$, we modify the $\mathrm{IV}$ using the same method as above. This time, we do not use $c_2$ and request a decryption of $(\mathrm{IV}', c_1)$ only. If some $\mathrm{IV}'$ gives a decryption result that ends with $8$ bytes of $\texttt{0x08}$, we have that
-
-$$
-\mathrm{IV}' \oplus D_k(c_1) = \texttt{0x08}^8.
-$$
-
-Similarly, we recover $m_0$ by
-
-$$
-m_0 = \mathrm{IV} \oplus D_k(c_1) = \mathrm{IV} \oplus \mathrm{IV}' \oplus \texttt{0x08}^8.
-$$
-
-## Hashed MAC (HMAC)
-
-Let $H$ be a has function. We defined MAC as $H(k \parallel m)$ where $k$ is a key and $m$ is a message. This MAC is insecure if $H$ has [Merkle-Damgård construction](../../modern-cryptography/2023-09-28-hash-functions#merkle-damg%C3%A5rd-transform), since it is vulnerable to length extension attacks. See [prepending the key in MAC is insecure (Modern Cryptography)](../../modern-cryptography/2023-09-28-hash-functions#prepending-the-key).
-
-Choose a key $k \leftarrow \mathcal{K}$, and set
-
-$$
-k_1 = k \oplus \texttt{ipad}, \quad k_2 = k\oplus \texttt{opad}
-$$
-
-where $\texttt{ipad} = \texttt{0x363636}...$ and $\texttt{opad} = \texttt{0x5C5C5C}...$. Then
-
-$$
-\mathrm{HMAC}(k, m) = H(k_2 \parallel H(k_1 \parallel m)).
-$$
-
-## TLS Details
-
-- TLS consists of two main protocols (4 in total)
-- **Handshake protocol** is the most important.
-	- Uses public key cryptography to share a secret key between the client and the server.
-- Record protocol
-	- Use the shared key from the handshake to protect communication.
-
-### TLS Handshake Protocol
-
-Here's how the client and the server establishes a connection using the TLS handshake protocol. (TLS 1.2, RFC 5246)
-
-> 1. Two parties agree on the following.
-> 	- The version of the protocol.
-> 	- The set of cipher suites (cryptographic algorithms) to be used.
-> 2. The client uses digital certificates to authenticate the server.
-> 3. Use the server's public key to share a secret.
-> 4. Both parties generate a symmetric key from the shared secret.
-
-![is-09-tls-handshake.png](/assets/img/posts/Lecture%20Notes/Internet%20Security/is-09-tls-handshake.png)[^1]
-
-- `ServerKeyExchange`, `ClientKeyExchange` is optional. Used sometimes if Diffie-Hellman is used.
-- The actual messages and process differ for each protocol and ciphers used.
-- **All messages after `ChangeCipherSpec` are encrypted.**
-
-#### ClientHello
-
-- Client sends the TLS protocol version and cipher suites that it supports.
-	- The version is the highest version supported by the client.
-- A random number $N_c$ for generating the secret is sent.
-- A session ID may be sent if the client wants to resume an old session.
-
-#### ServerHello
-
-- Server sends the TLS version and cipher suite to use.
-	- The TLS version will be the highest version supported by both parties.
-	- The server will pick the strongest cryptographic algorithm offered by the client.
-- The server also sends a random number $N_s$.
-
-#### Certificate/ServerKeyExchange
-
-- The server sends its public key certificate.
-	- The actual data depends on the cipher suite used.
-	- For example, it can contain RSA public key, or Diffie-Hellman public key.
-- The server will send `ServerHelloDone`.
-- The client will verify the server's certificate.
-
-#### ClientKeyExchange
-
-- Client sends *premaster secret* (PMS) $secret_c$.
-	- This is encrypted with server's public key.
-	- This secret key material will be used to generate the secret key.
-- Both parties derive a shared **session key** from $N_c$, $N_s$, $secret_c$.
-	- If the protocol is correct, the same key should be generated.
-
-#### Finished
-
-Both parties now switch to encrypted communication. Both parties exchange a `Finished` message.
-
-- This message is the first message protected by the previously agreed cipher.
-- The message contains the **hash** of all sent and received messages during the handshake.
-- This is to ensure that the key exchange and authentication process were successful and the messages were not tampered with.
-- The hash must be verified by the other side.
-
-More information in [Section 7.4.9 (RFC 5246)](https://www.rfc-editor.org/rfc/rfc5246#section-7.4.9).
-
-### Generating Master and Secret Keys
-
-This is from the RFC 5246 document. PRF is a pseudorandom function.
-
-```
-master_secret = PRF(pre_master_secret, "master secret",
-					ClientHello.random + ServerHello.random)
-					[0..47];
-
-key_block = PRF(SecurityParameters.master_secret,
-				"key expansion",
-				SecurityParameters.server_random +
-				SecurityParameters.client_random);
-```
-
-- Why do we use `pre_master_secret` and `master_secret`?
-	- To provide greater consistency between TLS cipher suites.[^2]
-
-## Version Rollback Attack (SSL)
-
-- Client sends TLS version 3.0, but the attacker in the middle modifies it and sends version 2.0.
-- Server thinks that the client only supports SSL 2.0.
-- Then the client and the server communicates using SSL 2.0, which may be insecure.
-
-### Chosen Protocol Attacks
-
- - Also known as **Downgrade Attacks**.
-	 - Dangerous since old versions have security vulnerabilities.
- - Attackers can perform attacks using the old, broken version.
-	 - Weak protocols, weak cryptographic algorithms, etc.
- - Newer versions (patched) must be *backward-compatible*, since not all people upgrade right away.
- - Methods to prevent this attack.
-	 - Drop backward compatibility.
-	 - Authenticate the version number.
-
-#### Version Checking in SSL 3.0
-
-- When sending the premaster secret, also send the protocol version.
-	- This data is encrypted with the server's public key, so it cannot be tampered.
-- The server will decrypt and check if the protocol version matches the version in the `ClientHello` message.
-
-## Other TLS/SSL Protocols
-
-These two protocols run over the record protocol.
-
-- **Alert protocol**
-	- Handling of sessions, warnings and errors.
-- **Change cipher spec protocol**
-	- Not a part of handshake protocol.
-	- Indicates that the parties are changing to the agreed cipher suite.
-
-## Issues in TLS 1.2
-
-- **Forward secrecy** is not supported.
-- It used weak cryptographic algorithms.
-- Compression is not as efficient.
-
-### Forward Secrecy
-
-> **Forward secrecy** is a feature of key agreement protocols that session keys will not be compromised even if long-term secrets used in the session key exchange are compromised.[^3]
-
-> An encryption system has the property of **forward secrecy** if plaintext (decrypted) inspection of the data exchange that occurs during key agreement phase of session initiation does not reveal the key that was used to encrypt the remainder of the session.[^3]
-
-- Forward secrecy prevents an **NSA-style attack**.
-	- Save all TLS traffic starting from TLS handshake.
-	- Obtain the server's private key later with a court order or hacking in.
-	- Decrypt all the stored traffic.
-- If an ephemeral session key is used for each new message, forward secrecy is provided.
-	- Other messages cannot be decrypted even if a session key is compromised.
-- From TLS 1.3, fixed by only using Diffie-Hellman ephemeral (`DHE-*`) ciphers.
-
-### DH-RSA and DHE-RSA
-
-Actual secret sharing is done using Diffie-Hellman key exchange, and RSA is used for digital signatures.
-
-#### DH-RSA
-
-- Server's **permanent** key pair is a Diffie-Hellman key pair.
-	- Certificate has the server's public key $g^s \bmod p$.
-	- Certificate is signed by the CA using RSA.
-- The client sends $g^c \bmod p$.
-
-#### DHE-RSA
-
-- **For each TLS session**, the server generates a random number $s$.
-- The server's public key is $g^s \bmod p$.
-	- Certificate is signed using RSA.
-- The client sends $g^c \bmod p$.
-- The server and client agree on a secret $g^{sc} \bmod p$.
-- The ephemeral keys $s$ and $g^{sc} \bmod p$ is discarded after the session.
-
-## TLS 1.3
-
-- TLS 1.3 does not support RSA, nor other vulnerable cipher suites.
-- Shortened TLS handshake, thus faster and more secure.
-	- Reduced RTTs (round trip time).
-	- Achieves forward secrecy.
-
-### TLS 1.3 Handshake
-
-We previously had 2 round trips, but now we have one. The main difference is the client hello part.
-
-- **Client hello**
-	- Protocol version, client random, cipher suites are sent.
-	- **Parameters for calculating the premaster secret is also sent.**[^4]
-- **Server generates master secret**
-	- Server has client random, parameters and cipher suites.
-	- Using the server random, generate the master secret.
-- **Server hello** and **Finished**
-	- Server's certificate, digital signature, server random, chosen cipher suite is sent.
-	- Master secret has been generated, so `Finished` is sent.
-- **Client Finished**
-	- Client verifies the certificate, generates master secret, sends `Finished`.
-
-### 0-RTT for Session Resumption
-
-TLS 1.3 also supports an event faster handshake that doesn't require and round trips.
-
-- Works only if the user has visited the website before.
-- The both parties can derive another shared secret from the first session.
-	- **Resumption main secret**, **pre-shared key** (PSK)
-- The server sends a **session ticket** during the first session.
-	- The client sends this ticket along with the first encrypted message of the new session.
-
-#### Replay Attacks in 0-RTT
-
-0-RTT is susceptible to **replay attacks**.
-
-- Different servers (of the same domain) cannot catch replay attacks.
-- Initial data in TLS resumption should be handled carefully.
-	- For example, only allow methods that do not change state (like HTTP GET) without any parameters.
-
-Read more in [Introducing 0-RTT (Cloudflare Blog)](https://blog.cloudflare.com/introducing-0-rtt/).
-
-[^1]: Source: [The SSL Store](https://www.thesslstore.com/blog/explaining-ssl-handshake/).
-[^2]: Source: [Cryptography SE](https://crypto.stackexchange.com/questions/24780/what-is-the-purpose-of-pre-master-secret-in-ssl-tls).
-[^3]: Source: [Forward secrecy (Wikipedia)](https://en.wikipedia.org/wiki/Forward_secrecy).
-[^4]: The client is assuming that it knows the server's preferred key exchange method, since many insecure cipher suites have been removed. Now, the number of possible cipher suites has been reduced.

_posts/lecture-notes/internet-security/2023-09-10-security-intro.md

@@ -5,6 +5,7 @@ math: false
 categories:
   - Lecture Notes
   - Internet Security
+path: _posts/lecture-notes/internet-security
 tags:
   - network
   - security
@@ -13,9 +14,9 @@ title: 01. Security Introduction
 date: 2023-09-10
 github_title: 2023-09-10-security-intro
 image:
-  path: /assets/img/posts/Lecture Notes/Internet Security/is-01-cryptosystem.png
+  path: /assets/img/posts/lecture-notes/internet-security/is-01-cryptosystem.png
 attachment:
-  folder: assets/img/posts/Lecture Notes/Internet Security
+  folder: assets/img/posts/lecture-notes/internet-security
 ---
 
 > Every program has at least two purposes: the one for which it was written, and another for which it wasn't. - Alan J. Perlis
@@ -155,7 +156,7 @@ There are many ways of achieving security.
 
 ### Basics of a Cryptosystem
 
-![is-01-cryptosystem.png](/assets/img/posts/Lecture%20Notes/Internet%20Security/is-01-cryptosystem.png)
+![is-01-cryptosystem.png](../../../assets/img/posts/lecture-notes/internet-security/is-01-cryptosystem.png)
 
 - A **message** in *plaintext* is given to an **encryption algorithm**.
 - The encryption algorithm uses an **encryption key** to create a *ciphertext*.

_posts/lecture-notes/internet-security/2023-09-11-symmetric-key-cryptography-1.md

@@ -5,6 +5,7 @@ math: true
 categories:
   - Lecture Notes
   - Internet Security
+path: _posts/lecture-notes/internet-security
 tags:
   - security
   - lecture-note
@@ -190,7 +191,7 @@ Let $m \in \left\lbrace 0, 1 \right\rbrace^n$ be the message to encrypt. Then ch
 - Encryption: $E(k, m) = k \oplus m$.
 - Decryption: $D(k, c) = k \oplus c$.
 
-This scheme is **provably secure**. See also [one-time pad (Modern Cryptography)](../Modern%20Cryptography/2023-09-07-otp-stream-cipher-prgs.md#one-time-pad-(otp)).
+This scheme is **provably secure**. See also [one-time pad (Modern Cryptography)](../modern-cryptography/2023-09-07-otp-stream-cipher-prgs.md#one-time-pad-(otp)).
 
 ## Perfect Secrecy
 
@@ -224,7 +225,7 @@ since for each $m$ and $c$, $k$ is determined uniquely.
 
 *Proof*. Assume not, then we can find some message $m_0 \in \mathcal{M}$ such that $m_0$ is not a decryption of some $c \in \mathcal{C}$. This is because the decryption algorithm $D$ is deterministic and $\lvert \mathcal{K} \rvert < \lvert \mathcal{M} \rvert$.
 
-For the proof in detail, check [Shannon's Theorem (Modern Cryptography)](../Modern%20Cryptography/2023-09-07-otp-stream-cipher-prgs.md#shannon's-theorem).
+For the proof in detail, check [Shannon's Theorem (Modern Cryptography)](../modern-cryptography/2023-09-07-otp-stream-cipher-prgs.md#shannon's-theorem).
 
 ### Two-Time Pad is Insecure
 

_posts/lecture-notes/internet-security/2023-09-18-symmetric-key-cryptography-2.md

@@ -5,6 +5,7 @@ math: true
 categories:
   - Lecture Notes
   - Internet Security
+path: _posts/lecture-notes/internet-security
 tags:
   - lecture-note
   - security
@@ -13,9 +14,9 @@ title: 03. Symmetric Key Cryptography (2)
 date: 2023-09-18
 github_title: 2023-09-18-symmetric-key-cryptography-2
 image:
-  path: /assets/img/posts/Lecture Notes/Internet Security/is-03-feistel-function.png
+  path: /assets/img/posts/lecture-notes/internet-security/is-03-feistel-function.png
 attachment:
-  folder: assets/img/posts/Lecture Notes/Internet Security
+  folder: assets/img/posts/lecture-notes/internet-security
 ---
 
 ## Block Cipher Overview
@@ -63,7 +64,7 @@ $$
 
 #### The Feistel Function
 
-![is-03-feistel-function.png](/assets/img/posts/Lecture%20Notes/Internet%20Security/is-03-feistel-function.png)
+![is-03-feistel-function.png](../../../assets/img/posts/lecture-notes/internet-security/is-03-feistel-function.png)
 
 The Feistel function takes $32$ bit data and divides it into eight $4$ bit chunks. Each chunk is expanded to $6$ bits using a P-box. Now, we have 48 bits of data, so apply XOR with the key for this round. Next, each $6$-bit block is compressed back to $4$ bits using a S-box. Finally, there is a (straight) permutation at the end, resulting in $32$ bit data.
 
@@ -179,7 +180,7 @@ AES, DES use fixed block size for encryption. How do we encrypt longer messages?
 
 ### Electronic Codebook Mode (ECB)
 
-![is-03-ecb-encryption.png](/assets/img/posts/Lecture%20Notes/Internet%20Security/is-03-ecb-encryption.png)
+![is-03-ecb-encryption.png](../../../assets/img/posts/lecture-notes/internet-security/is-03-ecb-encryption.png)
 
 - Codebook is a mapping table.
 - For the $i$-th plaintext block, we use key $k$ to encrypt and obtain the $i$-th ciphertext block.
@@ -198,9 +199,9 @@ Since the same key is used for all blocks, once a mapping from plaintext to ciph
 
 ### Cipher Block Chaining Mode (CBC)
 
-![is-03-cbc-encryption.png](/assets/img/posts/Lecture%20Notes/Internet%20Security/is-03-cbc-encryption.png)
+![is-03-cbc-encryption.png](../../../assets/img/posts/lecture-notes/internet-security/is-03-cbc-encryption.png)
 
-- Two identical messages produce to different ciphertexts.
+- Two identical messages produce two different ciphertexts.
 	- This prevents chosen plaintext attacks
 - Blocks are linked together in the encryption process
 	- **Each previous cipher block is chained with current block**
@@ -238,17 +239,18 @@ Since the same key is used for all blocks, once a mapping from plaintext to ciph
 	- **IV changes should be unpredictable**
 - On IV reuse, same message will generate the same ciphertext if key isn't changed
 - If IV is predictable, CBC is vulnerable to chosen plaintext attacks.
-	- Define Eve's new message $m' = \mathrm{IV} _ {\mathrm{E}} \oplus \mathrm{IV} _ {\mathrm{A}} \oplus g$, where
+	- Suppose Eve obtains $(\mathrm{IV}_1, E_k(\mathrm{IV}_1 \oplus m))$.
-		- $\mathrm{IV} _ \mathrm{A}$ and $\mathrm{IV} _ \mathrm{E}$ are Alice and Eve's IVs
+	- Define Eve's new message $m' = \mathrm{IV} _  {2} \oplus \mathrm{IV} _ {1} \oplus g$, where
+		- $\mathrm{IV} _ 2$ is the guess of the next IV, and
 		- $g$ is a guess of Alice's original message $m$.
-	- Since Eve can encrypt any message, $m'$ can be encrypted.
+	- Eve requests an encryption of $m'$
-	- $c' = E _ k(\mathrm{IV} _ \mathrm{E} \oplus m') = E _ k(\mathrm{IV} _ \mathrm{A} \oplus g)$.
+		- $c' = E _ k(\mathrm{IV} _ 2 \oplus m') = E _ k(\mathrm{IV} _ \mathrm{1} \oplus g)$.
-	- Then Eve can compare $c'$ and the original $c = E _ k(\mathrm{IV} _ \mathrm{A} \oplus m)$ to recover $m$.
+	- Then Eve can compare $c'$ and the original $c = E _ k(\mathrm{IV} _ \mathrm{1} \oplus m)$ to recover $m$.
 	- Useful when there are not many cases for $m$ (or most of the message is already known).
 
 ### Cipher Feedback Mode (CFB)
 
-![is-03-cfb-encryption.png](/assets/img/posts/Lecture%20Notes/Internet%20Security/is-03-cfb-encryption.png)
+![is-03-cfb-encryption.png](../../../assets/img/posts/lecture-notes/internet-security/is-03-cfb-encryption.png)
 
 - The message is treated as a stream of bits; similar to stream cipher
 - **Result of the encryption is fed to the next stage.**
@@ -283,7 +285,7 @@ Since the same key is used for all blocks, once a mapping from plaintext to ciph
 
 ### Output Feedback Mode (OFB)
 
-![is-03-ofb-encryption.png](/assets/img/posts/Lecture%20Notes/Internet%20Security/is-03-ofb-encryption.png)
+![is-03-ofb-encryption.png](../../../assets/img/posts/lecture-notes/internet-security/is-03-ofb-encryption.png)
 
 - Very similar to stream cipher.
 - Initialization vector is used as a seed to generate the key stream.
@@ -316,7 +318,7 @@ Since the same key is used for all blocks, once a mapping from plaintext to ciph
 
 ### Counter Mode (CTR)
 
-![is-03-ctr-encryption.png](/assets/img/posts/Lecture%20Notes/Internet%20Security/is-03-ctr-encryption.png)
+![is-03-ctr-encryption.png](../../../assets/img/posts/lecture-notes/internet-security/is-03-ctr-encryption.png)
 
 - Without chaining, we use a counter (typically incremented by $1$).
 	- Counter starts from the initialization vector.

_posts/lecture-notes/internet-security/2023-09-25-modular-arithmetic-1.md

@@ -5,6 +5,7 @@ math: true
 categories:
   - Lecture Notes
   - Internet Security
+path: _posts/lecture-notes/internet-security
 tags:
   - lecture-note
   - security

_posts/lecture-notes/internet-security/2023-10-04-modular-arithmetic-2.md

@@ -5,6 +5,7 @@ math: true
 categories:
   - Lecture Notes
   - Internet Security
+path: _posts/lecture-notes/internet-security
 tags:
   - lecture-note
   - security

_posts/lecture-notes/internet-security/2023-10-04-rsa-elgamal.md

@@ -5,6 +5,7 @@ math: true
 categories:
   - Lecture Notes
   - Internet Security
+path: _posts/lecture-notes/internet-security
 tags:
   - lecture-note
   - security
@@ -139,7 +140,7 @@ This is an inverse problem of exponentiation. The inverse of exponentials is log
 
 Given $y \equiv g^x \pmod p$ for some prime $p$, we want to find $x = \log_g y$. We set $g$ to be a generator of the group $\mathbb{Z}_p$ or $\mathbb{Z}_p^*$, since if $g$ is the generator, a solution always exists.
 
-Read more in [discrete logarithm problem (Modern Cryptography)](../../modern-cryptography/2023-10-03-key-exchange#discrete-logarithm-problem-dl).
+Read more in [discrete logarithm problem (Modern Cryptography)](../modern-cryptography/2023-10-03-key-exchange.md#discrete-logarithm-problem-(dl)).
 
 ## ElGamal Encryption
 

_posts/lecture-notes/internet-security/2023-10-09-public-key-cryptography.md

@@ -5,6 +5,7 @@ math: true
 categories:
   - Lecture Notes
   - Internet Security
+path: _posts/lecture-notes/internet-security
 tags:
   - lecture-note
   - security
@@ -14,7 +15,7 @@ date: 2023-10-09
 github_title: 2023-10-09-public-key-cryptography
 ---
 
-In symmetric key cryptography, we have a problem with key sharing and management. More info in the first few paragraphs of [Key Exchange (Modern Cryptography)](../../modern-cryptography/2023-10-03-key-exchange).
+In symmetric key cryptography, we have a problem with key sharing and management. More info in the first few paragraphs of [Key Exchange (Modern Cryptography)](../modern-cryptography/2023-10-03-key-exchange.md).
 
 ## Public Key Cryptography
 
@@ -31,7 +32,7 @@ These keys are created to be used in **trapdoor one-way functions**.
 
 A **one-way function** is a function that is easy to compute, but hard to compute the pre-image of any output. Here are some common examples.
 
-- *Cryptographic hash functions*: [Hash Functions (Modern Cryptography)](../../modern-cryptography/2023-09-28-hash-functions#collision-resistance).
+- *Cryptographic hash functions*: [Hash Functions (Modern Cryptography)](../modern-cryptography/2023-09-28-hash-functions.md#collision-resistance).
 - *Factoring a large integer*: It is easy to multiply to integers even if they're large, but factoring is very hard.
 - *Discrete logarithm problem*: It is easy to exponentiate a number, but it is hard to find the discrete logarithm.
 
@@ -86,7 +87,7 @@ Choose a large prime $p$ and a generator $g$ of $\mathbb{Z}_p^{ * }$. The descri
 > 3. Alice and Bob calculate $g^{xy} \bmod p$ separately.
 > 4. Eve can see $g^x \bmod p$, $g^y \bmod p$ but cannot calculate $g^{xy} \bmod p$.
 
-Refer to [Diffie-Hellman Key Exchange (Modern Cryptography)](../../modern-cryptography/2023-10-03-key-exchange#diffie-hellman-key-exchange-dhke).
+Refer to [Diffie-Hellman Key Exchange (Modern Cryptography)](../modern-cryptography/2023-10-03-key-exchange.md#diffie-hellman-key-exchange-(dhke)).
 
 ## Message Integrity
 
@@ -132,7 +133,7 @@ Suppose Alice wants to **sign** a message $m$. Alice has public key $pk$ and pri
 > 2. Bob receives it and calculates $E(pk, \sigma)$ and compares it with $m$.
 > 	- The key $pk$ here is Alice's public key.
 
-- Since the signature can be decrypted using Alice's public key, it must have been signed using Alice's private key.
+- Since the signature can be verified using Alice's public key, it must have been signed using Alice's private key.
 	- Thus the message must have been from Alice.
 - Verification is done using Alice's public key, so anyone can verify the message.
 - Messages are usually long, so we take a hash function $H$ to shorten it, and sign $H(m)$ instead.

_posts/lecture-notes/internet-security/2023-10-16-pki.md

@@ -5,6 +5,7 @@ math: true
 categories:
   - Lecture Notes
   - Internet Security
+path: _posts/lecture-notes/internet-security
 tags:
   - lecture-note
   - security
@@ -12,7 +13,7 @@ title: 08. Public Key Infrastructure
 date: 2023-10-16
 github_title: 2023-10-16-pki
 attachment:
-  folder: assets/img/posts/Lecture Notes/Internet Security
+  folder: assets/img/posts/lecture-notes/internet-security
 ---
 
 Suppose that we're using RSA, Alice has public key $(N, e)$ and private key $d$. Anyone can send messages to Alice using $(N, e)$. But because anyone can generate $(N, e)$, we are not sure whether the key $(N, e)$ is *really* Alice's key. We might run into a situation where $(N, e)$ was actually some other person's key. *How do we check whose key this is?*
@@ -83,7 +84,7 @@ We have a root CA at the top. Then there are issuing CAs below. We usually reque
 
 ### Certificate Validation
 
-![is-08-certificate-validation.png](/assets/img/posts/Lecture%20Notes/Internet%20Security/is-08-certificate-validation.png)[^1]
+![is-08-certificate-validation.png](../../../assets/img/posts/lecture-notes/internet-security/is-08-certificate-validation.png)[^1]
 
 Since we have a hierarchy of CAs, certificate validation must also follow the hierarchy. When we receive a certificate, it is highly likely to be signed by an non-root CA.
 
@@ -149,13 +150,13 @@ CRL checking is done in the following way.
 > 2. The client queries the certificate revocation server and downloads CRLs.
 > 3. The client checks whether the certificate is revoked or not.
 
-But Distributing CRL in real-time is not possible. Furthermore, CRL lifecycles/update periods can vary depending on CAs. Thus there can be attacks between CRL updates. Also, CRL sizes will keep increasing over time, so it gets harder to download and manage the CRLs.
+But distributing CRL in real-time is not possible. Furthermore, CRL lifecycles/update periods can vary depending on CAs. Thus there can be attacks between CRL updates. Also, CRL sizes will keep increasing over time, so it gets harder to download and manage the CRLs.
 
 ### Online Certificate Status Protocol (OCSP)
 
 The **online certificate status protocol** (OCSP) is another way to handle certificate revocation. Basically, the client queries a OCSP server for revocation information.
 
-There is a **OCSP server** that runs 24/7, responding to queries. This server can be run by the CAs or may be delegated to some other entities. The address of the OCSP server is specified in the certificate.
+There is an **OCSP server** that runs 24/7, responding to queries. This server can be run by the CAs or may be delegated to some other entities. The address of the OCSP server is specified in the certificate.
 
 Using OCSP, revocation check is done in the following way.
 

_posts/lecture-notes/modern-cryptography/2023-09-07-otp-stream-cipher-prgs.md

@@ -14,9 +14,9 @@ title: 1. One-Time Pad, Stream Ciphers and PRGs
 date: 2023-09-07
 github_title: 2023-09-07-otp-stream-cipher-prgs
 image:
-  path: assets/img/posts/Lecture Notes/Modern Cryptography/mc-01-ss.png
+  path: assets/img/posts/lecture-notes/modern-cryptography/mc-01-ss.png
 attachment:
-  folder: assets/img/posts/Lecture Notes/Modern Cryptography
+  folder: assets/img/posts/lecture-notes/modern-cryptography
 ---
 
 ## Assumptions and Notations
@@ -293,7 +293,7 @@ We can deduce that if a PRG is predictable, then it is insecure.
 
 *Proof*. Let $\mathcal{A}$ be an efficient adversary (next bit predictor) that predicts $G$. Suppose that $i$ is the index chosen by $\mathcal{A}$. With $\mathcal{A}$, we construct a statistical test $\mathcal{B}$ such that $\mathrm{Adv}_\mathrm{PRG}[\mathcal{B}, G]$ is non-negligible.
 
-![mc-01-prg-game.png](../../../assets/img/posts/Lecture%20Notes/Modern%20Cryptography/mc-01-prg-game.png)
+![mc-01-prg-game.png](../../../assets/img/posts/lecture-notes/modern-cryptography/mc-01-prg-game.png)
 
 1. The challenger PRG will send a bit string $x$ to $\mathcal{B}$.
 	- In experiment $0$, PRG gives pseudorandom string $G(k)$.
@@ -319,7 +319,7 @@ The theorem implies that if next bit predictors cannot distinguish $G$ from true
 
 To motivate the definition of semantic security, we consider a **security game framework** (attack game) between a **challenger** (ex. the creator of some cryptographic scheme) and an **adversary** $\mathcal{A}$ (ex. attacker of the scheme).
 
-![mc-01-ss.png](../../../assets/img/posts/Lecture%20Notes/Modern%20Cryptography/mc-01-ss.png)
+![mc-01-ss.png](../../../assets/img/posts/lecture-notes/modern-cryptography/mc-01-ss.png)
 
 > **Definition.** Let $\mathcal{E} = (G, E, D)$ be a cipher defined over $(\mathcal{K}, \mathcal{M}, \mathcal{C})$. For a given adversary $\mathcal{A}$, we define two experiments $0$ and $1$. For $b \in \lbrace 0, 1 \rbrace$, define experiment $b$ as follows:
 >

_posts/lecture-notes/modern-cryptography/2023-09-12-prfs-prps-block-ciphers.md

@@ -14,9 +14,9 @@ title: 2. PRFs, PRPs and Block Ciphers
 date: 2023-09-12
 github_title: 2023-09-12-prfs-prps-block-ciphers
 image:
-  path: assets/img/posts/Lecture Notes/Modern Cryptography/mc-02-block-cipher.png
+  path: assets/img/posts/lecture-notes/modern-cryptography/mc-02-block-cipher.png
 attachment:
-  folder: assets/img/posts/Lecture Notes/Modern Cryptography
+  folder: assets/img/posts/lecture-notes/modern-cryptography
 ---
 
 ## Pseudorandom Functions (PRF)
@@ -119,7 +119,7 @@ This is a matter of *collisions* of $f(x_i)$, so we use the facts from the birth
 
 A **block cipher** is actually a different name for PRPs. Since a PRP $E$ is a keyed function, applying $E(k, x)$ is in fact encryption, and applying its inverse is decryption.
 
-![mc-02-block-cipher.png](../../../assets/img/posts/Lecture%20Notes/Modern%20Cryptography/mc-02-block-cipher.png)
+![mc-02-block-cipher.png](../../../assets/img/posts/lecture-notes/modern-cryptography/mc-02-block-cipher.png)
 
 Block ciphers commonly have the following form.
 - A key $k$ is chosen uniformly from $\left\lbrace 0, 1 \right\rbrace^s$.
@@ -141,7 +141,7 @@ Block ciphers commonly have the following form.
 
 Since block ciphers are PRPs, we have to build an invertible function. Suppose we are given **any** functions $F_1, \dots, F_d : \left\lbrace 0, 1 \right\rbrace^n \rightarrow \left\lbrace 0, 1 \right\rbrace^n$. Can we build an **invertible** function $F : \left\lbrace 0, 1 \right\rbrace^{2n} \rightarrow \left\lbrace 0, 1 \right\rbrace^{2n}$?
 
-![mc-02-feistel-network.png](../../../assets/img/posts/Lecture%20Notes/Modern%20Cryptography/mc-02-feistel-network.png)
+![mc-02-feistel-network.png](../../../assets/img/posts/lecture-notes/modern-cryptography/mc-02-feistel-network.png)
 
 It turns out the answer is yes. Given an $2n$-bit long input, $L_0$ and $R_0$ denote the left and right halves ($n$ bits) of the input, respectively. Define
 
@@ -161,7 +161,7 @@ Note that we did not require $F_i$ to be invertible. We can build invertible fun
 
 In DES, the function $F_i$ is the DES round function.
 
-![mc-02-des-round.png](../../../assets/img/posts/Lecture%20Notes/Modern%20Cryptography/mc-02-des-round.png)
+![mc-02-des-round.png](../../../assets/img/posts/lecture-notes/modern-cryptography/mc-02-des-round.png)
 
 The Feistel function takes $32$ bit data and divides it into eight $4$ bit chunks. Each chunk is expanded to $6$ bits using $E$. Now, we have 48 bits of data, so apply XOR with the key for this round. Next, each $6$-bit block is compressed back to $4$ bits using a S-box. Finally, there is a permutation $P$ at the end, resulting in $32$ bit data.
 
@@ -169,7 +169,7 @@ The Feistel function takes $32$ bit data and divides it into eight $4$ bit chunk
 
 DES uses $56$ bit keys that generate $16$ rounds keys. The diagram below shows that DES has 16-round Feistel networks.
 
-![mc-02-DES.png](../../../assets/img/posts/Lecture%20Notes/Modern%20Cryptography/mc-02-DES.png)
+![mc-02-DES.png](../../../assets/img/posts/lecture-notes/modern-cryptography/mc-02-DES.png)
 
 The input goes through initial/final permutation, which are inverses of each other. These have no cryptographic significance, and just for engineering.
 
@@ -177,7 +177,7 @@ The input goes through initial/final permutation, which are inverses of each oth
 
 DES is not secure, since key space and block length is too small. Thankfully, we have a replacement called the **advanced encryption standard** (AES).
 
-![mc-02-aes-128.png](../../../assets/img/posts/Lecture%20Notes/Modern%20Cryptography/mc-02-aes-128.png)
+![mc-02-aes-128.png](../../../assets/img/posts/lecture-notes/modern-cryptography/mc-02-aes-128.png)
 
 - DES key only had $56$ bits, so DES was broken in the 1990s
 - NIST standardized AES in 2001, based on Rijndael cipher
@@ -255,7 +255,7 @@ Then the key space has increased (exponentially). As for 2DES, the key space is
 
 Unfortunately, 2DES is only secure as DES, with the attack strategy called **meet in the middle**. The idea is that if $c = E(k_1, E(k_2, m))$, then $D(k_1, c) = E(k_2, m)$.
 
-![mc-02-2des-mitm.png](../../../assets/img/posts/Lecture%20Notes/Modern%20Cryptography/mc-02-2des-mitm.png)
+![mc-02-2des-mitm.png](../../../assets/img/posts/lecture-notes/modern-cryptography/mc-02-2des-mitm.png)
 
 Since we have the plaintext and the ciphertext, we first build a table of $(k, E(k_2, m))$ over $k_2 \in \mathcal{K}$ and sort by $E(k_2, m)$. Next, we check if $D(k_1, c)$ is in the table for all $k_1 \in \mathcal{K}$.
 

_posts/lecture-notes/modern-cryptography/2023-09-21-macs.md

@@ -14,9 +14,9 @@ title: 4. Message Authentication Codes
 date: 2023-09-21
 github_title: 2023-09-21-macs
 image:
-  path: assets/img/posts/Lecture Notes/Modern Cryptography/mc-04-mac-security.png
+  path: assets/img/posts/lecture-notes/modern-cryptography/mc-04-mac-security.png
 attachment:
-  folder: assets/img/posts/Lecture Notes/Modern Cryptography
+  folder: assets/img/posts/lecture-notes/modern-cryptography
 ---
 
 Message authentication codes (MAC) were designed to provide message integrity. Bob receives a message from Alice and wants to know if this message was not modified during transmission. For MACs, the message itself does not have to be secret. For example, when we download a file the file itself does not have to be protected, but we need a way to verify that the file was not modified.
@@ -27,7 +27,7 @@ On the other hand, MAC fixes data that is tampered in purpose. We will also requ
 
 ## Message Authentication Code
 
-![mc-04-mac.png](../../../assets/img/posts/Lecture%20Notes/Modern%20Cryptography/mc-04-mac.png)
+![mc-04-mac.png](../../../assets/img/posts/lecture-notes/modern-cryptography/mc-04-mac.png)
 
 > **Definition.** A **MAC** system $\Pi = (S, V)$ defined over $(\mathcal{K}, \mathcal{M}, \mathcal{T})$ is a pair of efficient algorithms $S$ and $V$ where $S$ is a **signing algorithm** and $V$ is a **verification algorithm**.
 > 
@@ -59,7 +59,7 @@ In the security definition of MACs, we allow the attacker to request tags for ar
 
 For strong MACs, the attacker only has to change the tag for the attack to succeed.
 
-![mc-04-mac-security.png](../../../assets/img/posts/Lecture%20Notes/Modern%20Cryptography/mc-04-mac-security.png)
+![mc-04-mac-security.png](../../../assets/img/posts/lecture-notes/modern-cryptography/mc-04-mac-security.png)
 
 > **Definition.** Let $\Pi = (S, V)$ be a MAC system defined over $(\mathcal{K}, \mathcal{M}, \mathcal{T})$. Given an adversary $\mathcal{A}$, the security game goes as follows.
 > 
@@ -124,7 +124,7 @@ The above construction uses a PRF, so it is restricted to messages of fixed size
 
 ### CBC-MAC
 
-![mc-04-cbc-mac.png](../../../assets/img/posts/Lecture%20Notes/Modern%20Cryptography/mc-04-cbc-mac.png)
+![mc-04-cbc-mac.png](../../../assets/img/posts/lecture-notes/modern-cryptography/mc-04-cbc-mac.png)
 
 > **Definition.** For any message $m = (m_0, m_1, \dots, m_{l-1}) \in \left\lbrace 0, 1 \right\rbrace^{nl}$, let $F_k := F(k, \cdot)$.
 > 
@@ -212,7 +212,7 @@ Since CBC-MAC is vulnerable to extension attacks, we encrypt the last block agai
 
 ECBC-MAC doesn't require us to know the message length in advance, but it is relatively expensive in practice, since a block cipher has to be initialized with a new key.
 
-![mc-04-ecbc-mac.png](../../../assets/img/posts/Lecture%20Notes/Modern%20Cryptography/mc-04-ecbc-mac.png)
+![mc-04-ecbc-mac.png](../../../assets/img/posts/lecture-notes/modern-cryptography/mc-04-ecbc-mac.png)
 
 > **Theorem.** Let $F : \mathcal{K} \times X \rightarrow X$ be a secure PRF. Then for any $l \geq 0$, $F_\mathrm{ECBC} : \mathcal{K}^2 \times X^{\leq l} \rightarrow X$ is a secure PRF.
 > 

_posts/lecture-notes/modern-cryptography/2023-09-26-cca-security-authenticated-encryption.md

@@ -14,9 +14,9 @@ title: 5. CCA-Security and Authenticated Encryption
 date: 2023-09-26
 github_title: 2023-09-26-cca-security-authenticated-encryption
 image:
-  path: assets/img/posts/Lecture Notes/Modern Cryptography/mc-05-ci.png
+  path: assets/img/posts/lecture-notes/modern-cryptography/mc-05-ci.png
 attachment:
-  folder: assets/img/posts/Lecture Notes/Modern Cryptography
+  folder: assets/img/posts/lecture-notes/modern-cryptography
 ---
 
 Previously, we focused on semantic security against **passive adversaries**, that only eavesdrop on the ciphertext. But in the real world, there are **active adversaries** that interfere with the communication, or even modify them.
@@ -84,7 +84,7 @@ The attacker shouldn't be able to create a new ciphertext that decrypts properly
 
 In this case, we fix the decryption algorithm so that $D : \mathcal{K} \times \mathcal{C} \rightarrow \mathcal{M} \cup \left\lbrace \bot \right\rbrace$, where $\bot$ means that the ciphertext was rejected.
 
-![mc-05-ci.png](../../../assets/img/posts/Lecture%20Notes/Modern%20Cryptography/mc-05-ci.png)
+![mc-05-ci.png](../../../assets/img/posts/lecture-notes/modern-cryptography/mc-05-ci.png)
 
 > **Definition.** Let $\mathcal{E} = (E, D)$ be a cipher defined over $(\mathcal{K}, \mathcal{M}, \mathcal{C})$. Given an adversary $\mathcal{A}$, the security game goes as follows.
 > 
@@ -139,7 +139,7 @@ Most natural constructions of CCA secure schemes satisfy AE, so we don't need to
 
 We want to combine CPA secure scheme and strongly secure MAC to get AE. Rather than focusing on the internal structure of the scheme, we want a general method to compose these two secure schemes so that we can get a AE secure scheme. We will see 3 examples.
 
-![mc-05-etm-mte.png](../../../assets/img/posts/Lecture%20Notes/Modern%20Cryptography/mc-05-etm-mte.png)
+![mc-05-etm-mte.png](../../../assets/img/posts/lecture-notes/modern-cryptography/mc-05-etm-mte.png)
 
 ### Encrypt-and-MAC (E&M)
 

_posts/lecture-notes/modern-cryptography/2023-09-28-hash-functions.md

@@ -14,9 +14,9 @@ title: 6. Hash Functions
 date: 2023-09-28
 github_title: 2023-09-28-hash-functions
 image:
-  path: assets/img/posts/Lecture Notes/Modern Cryptography/mc-06-merkle-damgard.png
+  path: assets/img/posts/lecture-notes/modern-cryptography/mc-06-merkle-damgard.png
 attachment:
-  folder: assets/img/posts/Lecture Notes/Modern Cryptography
+  folder: assets/img/posts/lecture-notes/modern-cryptography
 ---
 
 Hash functions are functions that take some input an compress them to produce an output of fixed size, usually just called *hash* or *digest*. A desired property of hash function is **collision resistance**.
@@ -107,7 +107,7 @@ Now we want to construct collision resistant hash functions that work for arbitr
 
 The Merkle-Damgård transform gives as a way to extend our input domain of the hash function by iterating the function.
 
-![mc-06-merkle-damgard.png](../../../assets/img/posts/Lecture%20Notes/Modern%20Cryptography/mc-06-merkle-damgard.png)
+![mc-06-merkle-damgard.png](../../../assets/img/posts/lecture-notes/modern-cryptography/mc-06-merkle-damgard.png)
 
 > **Definition.** Let $h : \left\lbrace 0, 1 \right\rbrace^n \times \left\lbrace 0, 1 \right\rbrace^l \rightarrow \left\lbrace 0, 1 \right\rbrace^n$ be a hash function. The **Merkle-Damgård function derived from $h$** is a function $H$ that works as follows.
 > 
@@ -152,7 +152,7 @@ Now we only have to build a collision resistant compression function. We can bui
 
 Number theoretic primitives will be shown after we learn some number theory.[^3] An example is shown in [collision resistance using DL problem (Modern Cryptography)](./2023-10-03-key-exchange.md#collision-resistance-based-on-dl-problem).
 
-![mc-06-davies-meyer.png](../../../assets/img/posts/Lecture%20Notes/Modern%20Cryptography/mc-06-davies-meyer.png)
+![mc-06-davies-meyer.png](../../../assets/img/posts/lecture-notes/modern-cryptography/mc-06-davies-meyer.png)
 
 > **Definition.** Let $\mathcal{E} = (E, D)$ be a block cipher over $(\mathcal{K}, X, X)$ where $X = \left\lbrace 0, 1 \right\rbrace^n$. The **Davies-Meyer compression function derived from $E$** maps inputs in $X \times \mathcal{K}$ to outputs in $X$, defined as follows.
 > 
@@ -217,7 +217,7 @@ This can be thought of as blocking the length extension attack from prepending t
 
 ### HMAC Definition
 
-![mc-06-hmac.png](../../../assets/img/posts/Lecture%20Notes/Modern%20Cryptography/mc-06-hmac.png)
+![mc-06-hmac.png](../../../assets/img/posts/lecture-notes/modern-cryptography/mc-06-hmac.png)
 
 This is a variant of the two-key nest, but the difference is that the keys $k_1', k_2'$ are not independent. Choose a key $k \leftarrow \mathcal{K}$, and set
 

_posts/lecture-notes/modern-cryptography/2023-10-03-key-exchange.md

@@ -14,9 +14,9 @@ title: 7. Key Exchange
 date: 2023-10-03
 github_title: 2023-10-03-key-exchange
 image:
-  path: assets/img/posts/Lecture Notes/Modern Cryptography/mc-07-dhke.png
+  path: assets/img/posts/lecture-notes/modern-cryptography/mc-07-dhke.png
 attachment:
-  folder: assets/img/posts/Lecture Notes/Modern Cryptography
+  folder: assets/img/posts/lecture-notes/modern-cryptography
 ---
 
 In symmetric key encryption, we assumed that the two parties already share the same key. We will see how this can be done.
@@ -75,7 +75,7 @@ $$
 
 We assume that the description of $p$, $q$ and $g$ are generated at the setup and shared by all parties. Now the actual protocol goes like this.
 
-![mc-07-dhke.png](../../../assets/img/posts/Lecture%20Notes/Modern%20Cryptography/mc-07-dhke.png)
+![mc-07-dhke.png](../../../assets/img/posts/lecture-notes/modern-cryptography/mc-07-dhke.png)
 
 > 1. Alice chooses $\alpha \leftarrow \mathbb{Z}_q$ and computes $g^\alpha$.
 > 2. Bob chooses $\beta \leftarrow \mathbb{Z}_q$ and computes $g^\beta$.
@@ -190,7 +190,7 @@ Taking $\mathcal{O}(N)$ steps is impractical in the real world, due to many comm
 
 We assumed that the adversary only eavesdrops, but if the adversary carries out active attacks, then DHKE is not enough. The major problem is the lack of **authentication**. Alice and Bob are exchanging keys, but they both cannot be sure that there are in fact communicating with the other. An attacker can intercept messages and impersonate Alice or Bob. This attack is called a **man in the middle attack**, and this attack works on any key exchange protocol that lacks authentication.
 
-![mc-07-dhke-mitm.png](../../../assets/img/posts/Lecture%20Notes/Modern%20Cryptography/mc-07-dhke-mitm.png)
+![mc-07-dhke-mitm.png](../../../assets/img/posts/lecture-notes/modern-cryptography/mc-07-dhke-mitm.png)
 
 The adversary will impersonate Bob when communicating with Alice, and will do the same for Bob by pretending to be Alice. The values of $\alpha, \beta$ that Alice and Bob chose are not leaked, but the adversary can decrypt anything in the middle and obtain the plaintext.
 
@@ -212,7 +212,7 @@ Before Diffie-Hellman, Merkle proposed an idea for secure key exchange protocol
 
 The idea was to use *puzzles*, which are problems that can be solved with some effort.
 
-![mc-07-merkle-puzzles.png](../../../assets/img/posts/Lecture%20Notes/Modern%20Cryptography/mc-07-merkle-puzzles.png)
+![mc-07-merkle-puzzles.png](../../../assets/img/posts/lecture-notes/modern-cryptography/mc-07-merkle-puzzles.png)
 
 > Let $\mathcal{E} = (E, D)$ be a block cipher defined over $(\mathcal{K}, \mathcal{M})$.
 > 1. Alice chooses random pairs $(k_i, s_i) \leftarrow \mathcal{K} \times \mathcal{M}$ for $i = 1, \dots, L$.

_posts/lecture-notes/modern-cryptography/2023-10-26-digital-signatures.md

@@ -14,9 +14,9 @@ title: 10. Digital Signatures
 date: 2023-10-26
 github_title: 2023-10-26-digital-signatures
 image:
-  path: assets/img/posts/Lecture Notes/Modern Cryptography/mc-10-dsig-security.png
+  path: assets/img/posts/lecture-notes/modern-cryptography/mc-10-dsig-security.png
 attachment:
-  folder: assets/img/posts/Lecture Notes/Modern Cryptography
+  folder: assets/img/posts/lecture-notes/modern-cryptography
 ---
 
 ## Digital Signatures
@@ -57,7 +57,7 @@ $$
 
 The definition is similar to the [secure MAC](./2023-09-21-macs.md#secure-mac-unforgeability). The adversary can perform a **chosen message attack**, but cannot create an **existential forgery**.
 
-![mc-10-dsig-security.png](../../../assets/img/posts/Lecture%20Notes/Modern%20Cryptography/mc-10-dsig-security.png)
+![mc-10-dsig-security.png](../../../assets/img/posts/lecture-notes/modern-cryptography/mc-10-dsig-security.png)
 
 > **Definition.** Let $\mc{S} = (G, S, V)$ be a signature scheme defined over $(\mc{M}, \Sigma)$. Given an adversary $\mc{A}$, the game goes as follows.
 > 
@@ -184,7 +184,7 @@ This scheme is originally from the **Schnorr identification protocol**.
 
 Let $G = \left\langle g \right\rangle$ be a cyclic group of prime order $q$. We consider an interaction between two parties, prover $P$ and a verifier $V$. The prover has a secret $\alpha \in \Z_q$ and the verification key is $u = g^\alpha$. **$P$ wants to convince $V$ that he knows $\alpha$, but does not want to reveal $\alpha$**.
 
-![mc-10-schnorr-identification.png](../../../assets/img/posts/Lecture%20Notes/Modern%20Cryptography/mc-10-schnorr-identification.png)
+![mc-10-schnorr-identification.png](../../../assets/img/posts/lecture-notes/modern-cryptography/mc-10-schnorr-identification.png)
 
 The protocol $\mc{I}_\rm{sch} = (G, P, V)$ works as follows.
 
@@ -239,7 +239,7 @@ Schnorr's scheme was protected by a patent, so NIST opted for a ad-hoc signature
 
 How would you trust public keys? We introduce **digital certificates** for this.
 
-Read in [public key infrastructure (Internet Security)](../../Lecture%20Notes/Internet%20Security/2023-10-16-pki.md).
+Read in [public key infrastructure (Internet Security)](../internet-security/2023-10-16-pki.md).
 
 [^1]: A Graduate Course in Applied Cryptography
 [^2]: By using the [Fiat-Shamir transform](./2023-11-07-sigma-protocols.md#the-fiat-shamir-transform).

_posts/lecture-notes/modern-cryptography/2023-11-02-zkp-intro.md

@@ -14,9 +14,9 @@ title: 12. Zero-Knowledge Proof (Introduction)
 date: 2023-11-02
 github_title: 2023-11-02-zkp-intro
 image:
-  path: assets/img/posts/Lecture Notes/Modern Cryptography/mc-12-id-protocol.png
+  path: assets/img/posts/lecture-notes/modern-cryptography/mc-12-id-protocol.png
 attachment:
-  folder: assets/img/posts/Lecture Notes/Modern Cryptography
+  folder: assets/img/posts/lecture-notes/modern-cryptography
 ---
 
 - In 1980s, the notion of *zero knowledge* was proposed by Shafi Goldwasser, Silvio micali and Charles Rackoff.
@@ -28,7 +28,7 @@ attachment:
 
 ## Identification Protocol
 
-![mc-12-id-protocol.png](../../../assets/img/posts/Lecture%20Notes/Modern%20Cryptography/mc-12-id-protocol.png)
+![mc-12-id-protocol.png](../../../assets/img/posts/lecture-notes/modern-cryptography/mc-12-id-protocol.png)
 
 > **Definition.** An **identification protocol** is a triple of algorithms $\mc{I} = (G, P, V)$ satisfying the following.
 > 

_posts/lecture-notes/modern-cryptography/2023-11-07-sigma-protocols.md

@@ -14,9 +14,9 @@ title: 13. Sigma Protocols
 date: 2023-11-07
 github_title: 2023-11-07-sigma-protocols
 image:
-  path: assets/img/posts/Lecture Notes/Modern Cryptography/mc-13-sigma-protocol.png
+  path: assets/img/posts/lecture-notes/modern-cryptography/mc-13-sigma-protocol.png
 attachment:
-  folder: assets/img/posts/Lecture Notes/Modern Cryptography
+  folder: assets/img/posts/lecture-notes/modern-cryptography
 ---
 
 The previous [3-coloring example](./2023-11-02-zkp-intro.md#example-3-coloring) certainly works as a zero knowledge proof, but is quite slow, and requires a lot of interaction. There are efficient protocols for interactive proofs, we will study sigma protocols.
@@ -27,7 +27,7 @@ The previous [3-coloring example](./2023-11-02-zkp-intro.md#example-3-coloring)
 
 > **Definition.** An **effective relation** is a binary relation $\mc{R} \subset \mc{X} \times \mc{Y}$, where $\mc{X}$, $\mc{Y}$, $\mc{R}$ are efficiently recognizable finite sets. Elements of $\mc{Y}$ are called **statements**. If $(x, y) \in \mc{R}$, then $x$ is called a **witness for** $y$.
 
-![mc-13-sigma-protocol.png](../../../assets/img/posts/Lecture%20Notes/Modern%20Cryptography/mc-13-sigma-protocol.png)
+![mc-13-sigma-protocol.png](../../../assets/img/posts/lecture-notes/modern-cryptography/mc-13-sigma-protocol.png)
 
 > **Definition.** Let $\mc{R} \subset \mc{X} \times \mc{Y}$ be an effective relation. A **sigma protocol** for $\mc{R}$ is a pair of algorithms $(P, V)$ satisfying the following.
 > 
@@ -107,7 +107,7 @@ Also note that **the simulator is free to generate the messages in any convenien
 
 The Schnorr identification protocol is actually a sigma protocol. Refer to [Schnorr identification protocol (Modern Cryptography)](./2023-10-26-digital-signatures.md#the-schnorr-identification-protocol) for the full description.
 
-![mc-10-schnorr-identification.png](../../../assets/img/posts/Lecture%20Notes/Modern%20Cryptography/mc-10-schnorr-identification.png)
+![mc-10-schnorr-identification.png](../../../assets/img/posts/lecture-notes/modern-cryptography/mc-10-schnorr-identification.png)
 
 > The pair $(P, V)$ is a sigma protocol for the relation $\mc{R} \subset \mc{X} \times \mc{Y}$ where
 > 
@@ -165,7 +165,7 @@ $$
 
 goes as follows.
 
-![mc-13-okamoto.png](../../../assets/img/posts/Lecture%20Notes/Modern%20Cryptography/mc-13-okamoto.png)
+![mc-13-okamoto.png](../../../assets/img/posts/lecture-notes/modern-cryptography/mc-13-okamoto.png)
 
 > 1. $P$ computes random $\alpha_t, \beta_t \la \bb{Z}_q$ and sends commitment $u_t \la g^{\alpha_t}h^{\beta_t}$ to $V$.
 > 2. $V$ computes challenge $c \la \mc{C}$ and sends it to $P$.
@@ -192,7 +192,7 @@ $$
 
 goes as follows.
 
-![mc-13-chaum-pedersen.png](../../../assets/img/posts/Lecture%20Notes/Modern%20Cryptography/mc-13-chaum-pedersen.png)
+![mc-13-chaum-pedersen.png](../../../assets/img/posts/lecture-notes/modern-cryptography/mc-13-chaum-pedersen.png)
 
 > 1. $P$ computes random $\beta_t \la \bb{Z}_q$ and sends commitment $v_t \la g^{\beta_t}$, $w_t \la u^{\beta_t}$ to $V$.
 > 2. $V$ computes challenge $c \la \mc{C}$ and sends it to $P$.
@@ -223,7 +223,7 @@ $$
 
 goes as follows.
 
-![mc-13-gq-protocol.png](../../../assets/img/posts/Lecture%20Notes/Modern%20Cryptography/mc-13-gq-protocol.png)
+![mc-13-gq-protocol.png](../../../assets/img/posts/lecture-notes/modern-cryptography/mc-13-gq-protocol.png)
 
 > 1. $P$ computes random $x_t \la \bb{Z}_n^{\ast}$ and sends commitment $y_t \la x_t^e$ to $V$.
 > 2. $V$ computes challenge $c \la \mc{C}$ and sends it to $P$.

_posts/lecture-notes/modern-cryptography/2023-11-16-gmw-protocol.md

@@ -14,9 +14,9 @@ title: 16. The GMW Protocol
 date: 2023-11-16
 github_title: 2023-11-16-gmw-protocol
 image:
-  path: assets/img/posts/Lecture Notes/Modern Cryptography/mc-16-beaver-triple.png
+  path: assets/img/posts/lecture-notes/modern-cryptography/mc-16-beaver-triple.png
 attachment:
-  folder: assets/img/posts/Lecture Notes/Modern Cryptography
+  folder: assets/img/posts/lecture-notes/modern-cryptography
 ---
 
 There are two types of MPC protocols, **generic** and **specific**. Generic protocols can compute arbitrary functions. [Garbled circuits](./2023-11-14-garbled-circuits.md#garbled-circuits) were generic protocols, since it can be used to compute any boolean circuits. In contrast, the [summation protocol](./2023-11-09-secure-mpc.md#example-secure-summation) is a specific protocol that can only be used to compute a specific function. Note that generic protocols are not necessarily better, since specific protocols are much more efficient.
@@ -148,7 +148,7 @@ Indeed, $z_1, z_2$ are shares of $z$.[^2] See also Exercise 23.5.[^3]
 
 Now, in the actual computation of AND gates, proceed as follows.
 
-![mc-16-beaver-triple.png](../../../assets/img/posts/Lecture%20Notes/Modern%20Cryptography/mc-16-beaver-triple.png)
+![mc-16-beaver-triple.png](../../../assets/img/posts/lecture-notes/modern-cryptography/mc-16-beaver-triple.png)
 
 > Each $P_i$ has a share of inputs $a_i, b_i$ and a Beaver triple $(x_i, y_i, z_i)$.
 > 1. Each $P_i$ computes $u_i = a_i + x_i$, $v_i = b_i + y_i$.