fix: typo

This commit is contained in:
2026-01-08 11:15:47 +09:00
parent c4b9b32e16
commit 7bf64c849d
2 changed files with 41 additions and 41 deletions

View File

@@ -19,7 +19,7 @@ attachment:
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.
- In 1980s, the notion of *zero knowledge* was proposed by Shafi Goldwasser, Silvio Micali and Charles Rackoff.
- **Interactive proof systems**: a **prover** tries to convince the **verifier** that some statement is true, by exchanging messages.
- What if the prover is trying to trick the verifier?
- What if the verifier is an adversary that tries to obtain more information?
@@ -31,22 +31,22 @@ attachment:
![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.
>
>
> - $G$ is a probabilistic **key generation** algorithm that outputs $(vk, sk) \leftarrow G()$. $vk$ is the **verification key** and $sk$ is the **secret key**.
> - $P$ is an interactive protocol algorithm called the **prover**, which takes the secret key $sk$ as an input.
> - $V$ is an interactive protocol algorithm called the **verifier**, which takes the verification key $vk$ as an input and outputs $\texttt{accept}$ or $\texttt{reject}$.
>
>
> For all possible outputs $(vk, sk)$ of $G$, at the end of the interaction between $P(sk)$ and $V(vk)$, $V$ outputs $\texttt{accept}$ with probability $1$.
### Password Authentication
A client is trying to log in, must prove its identity to the server. But the client cannot trust the server (verifier), so the client must prove itself without revealing the secret. The password is the secret in this case. The login is a *proof* that the client is who it claims to be. What should be the verification key? Setting $vk = sk$ certainly works, but the server learns the password, so this should not be used.
During a log-in, a client must prove its identity to the server. But the client cannot trust the server (verifier), so the client must prove itself without revealing the secret. The password is the secret in this case. The login is a *proof* that the client is who it claims to be. What should be the verification key? Setting $vk = sk$ certainly works, but the server learns the password, so this should not be used.
Instead, we could set $vk = H(sk)$ by using a hash function $H$. Then the client sends the password, server computes the hash and checks if it is equal. This method still reveals the plaintext password to the server.
Instead, we could set $vk = H(sk)$ by using a hash function $H$. Then the client sends the password, server computes the hash and checks if it is equal. Note that this method still reveals the plaintext password to the server.
## Example: 3-Coloring
Suppose we are given a graph $G = (V, E)$, which we want to color the vertices with at most $3$ colors, so that no two adjacent vertices have the same color. This is an NP-complete problem.
Suppose we are given a graph $G = (V, E)$, which we want to color the vertices with at most $3$ colors so that no two adjacent vertices have the same color. This is an NP-complete problem.
Bob has a graph $G$ and he is trying to $3$-color the graph. Alice shows up and claims that there is a way to $3$-color $G$. If the coloring is valid, Bob is willing to buy the solution, but he cannot trust Alice. Bob won't pay until he is convinced that Alice has a solution, and Alice won't give the solution until she receives the money. How can Alice and Bob settle this problem?
@@ -82,26 +82,26 @@ We need three properties for a **zero-knowledge proof** (ZKP).
We define these formally.
> **Definition.** Let $\mc{R} \subset \mc{X} \times \mc{Y}$ be a relation. A statement $y \in \mc{Y}$ is **true** if $(x, y) \in \mc{R}$ for some $x \in \mc{X}$. The set of true statements
>
>
> $$
> L _ \mc{R} = \braces{y \in \mc{Y} : \exists x \in \mc{X},\; (x, y) \in \mc{R}}
> $$
>
>
> is called the **language** defined by $\mc{R}$.
> **Definition.** A **zero-knowledge proof** is a protocol between a prover $P(x, y)$ and a verifier $V(x)$. At the end of the protocol, the verifier either accepts or rejects.
In the above definition, $y$ is the statement to prove, and $x$ is the proof of that statement, which the prover wants to hide. The prover and the verifier exchanges messages for the protocol, and this collection of interactions is called the **view** (or conversation, transcript).
In the above definition, $y$ is the statement to prove, and $x$ is the proof of that statement which the prover wants to hide. The prover and the verifier exchanges messages for the protocol, and this collection of interactions is called the **view** (or conversation, transcript).
> **Definition.**
>
> - (**Completeness**) If $(x, y) \in R$, then an honest verifier accepts with very high probability.
> - (**Soundness**) If $y \notin L$, an honest verifier accepts with a negligible probability.
>
> - (**Completeness**) If $(x, y) \in \mc{R}$, then an honest verifier accepts with very high probability.
> - (**Soundness**) If $y \notin L_{\mc{R}}$, an honest verifier accepts with a negligible probability.
But how do we define *zero knowledge*? What is *knowledge*? If the verifier learns something, the verifier obtains something that he couldn't have computed without interacting with the prover. Thus, we define zero knowledge as the following.
> **Definition.** We say that a protocol is **honest verifier zero knowledge** (HVZK) if there exists an efficient algorithm $\rm{Sim}$ (simulator) on input $x$ such that the output distribution of $\rm{Sim}(x)$ is indistinguishable from the distribution of the verifier's view.
>
>
> $$
> \rm{Sim}(x) \approx \rm{View} _ V[P(x, y) \lra V(x)]
> $$