mirror of
https://github.com/calofmijuck/blog.git
synced 2025-12-06 22:53:51 +00:00
[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
This commit is contained in:
GitHub
@@ -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.
|
||||
|
||||
|
||||
|
||||
|
||||
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).
|
||||
|
||||
|
||||
|
||||
|
||||
> **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:
|
||||
>
|
||||
|
||||
@@ -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.
|
||||
|
||||
|
||||
|
||||
|
||||
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}$?
|
||||
|
||||
|
||||
|
||||
|
||||
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.
|
||||
|
||||
|
||||
|
||||
|
||||
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.
|
||||
|
||||
|
||||
|
||||
|
||||
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).
|
||||
|
||||
|
||||
|
||||
|
||||
- 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)$.
|
||||
|
||||
|
||||
|
||||
|
||||
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}$.
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
|
||||
|
||||
> **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.
|
||||
|
||||
|
||||
|
||||
|
||||
> **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
|
||||
|
||||
|
||||
|
||||
|
||||
> **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.
|
||||
|
||||
|
||||
|
||||
|
||||
> **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.
|
||||
>
|
||||
|
||||
@@ -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.
|
||||
|
||||
|
||||
|
||||
|
||||
> **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.
|
||||
|
||||
|
||||
|
||||
|
||||
### Encrypt-and-MAC (E&M)
|
||||
|
||||
|
||||
@@ -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.
|
||||
|
||||
|
||||
|
||||
|
||||
> **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).
|
||||
|
||||
|
||||
|
||||
|
||||
> **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
|
||||
|
||||
|
||||
|
||||
|
||||
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
|
||||
|
||||
|
||||
@@ -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.
|
||||
|
||||
|
||||
|
||||
|
||||
> 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.
|
||||
|
||||
|
||||
|
||||
|
||||
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.
|
||||
|
||||
|
||||
|
||||
|
||||
> 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$.
|
||||
|
||||
@@ -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**.
|
||||
|
||||
|
||||
|
||||
|
||||
> **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$**.
|
||||
|
||||
|
||||
|
||||
|
||||
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).
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
|
||||
|
||||
> **Definition.** An **identification protocol** is a triple of algorithms $\mc{I} = (G, P, V)$ satisfying the following.
|
||||
>
|
||||
|
||||
@@ -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$.
|
||||
|
||||
|
||||
|
||||
|
||||
> **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.
|
||||
|
||||
|
||||
|
||||
|
||||
> 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.
|
||||
|
||||
|
||||
|
||||
|
||||
> 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.
|
||||
|
||||
|
||||
|
||||
|
||||
> 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.
|
||||
|
||||
|
||||
|
||||
|
||||
> 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$.
|
||||
|
||||
@@ -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.
|
||||
|
||||
|
||||
|
||||
|
||||
> 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$.
|
||||
|
||||
Reference in New Issue
Block a user