feat: always include math

_includes/js-selector.html

@@ -64,7 +64,6 @@
 
 <script defer src="{{ script | relative_url }}"></script>
 
-{% if page.math %}
   <!-- MathJax -->
   <script src="{{ '/assets/js/data/mathjax.js' | relative_url }}"></script>
   <script>
@@ -145,7 +144,6 @@
   </script>
   <script async src="https://cdnjs.cloudflare.com/polyfill/v3/polyfill.min.js?features=es6"></script>
   <script id="MathJax-script" async src="{{ site.data.origin[type].mathjax.js | relative_url }}"></script>
-{% endif %}
 
 <!-- Pageviews -->
 {% if page.layout == 'post' %}

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

@@ -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?
@@ -40,13 +40,13 @@ attachment:
 
 ### 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?
 
@@ -91,12 +91,12 @@ We define these formally.
 
 > **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.
 

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

@@ -19,7 +19,7 @@ attachment:
   folder: assets/img/posts/lecture-notes/modern-cryptography
 ---
 
-The previous [3-coloring example](../2023-11-02-zkp-intro/#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.
+The previous [3-coloring example](../2023-11-02-zkp-intro/#example-3-coloring) certainly works as a zero knowledge proof, but is quite slow, and requires a lot of interaction. We will now turn our attention to **sigma protocols**, which offer a more efficient framework for interactive proofs.
 
 ## Sigma Protocols
 
@@ -70,9 +70,7 @@ For sigma protocols, it suffices to require **special soundness**.
 
 The extractor efficiently finds a proof $x$ for $y \in \mc{Y}$. This means, if a possibly cheating prover $P^{\ast}$ makes $V$ accept $y$ with non-negligible probability, then $P^{\ast}$ must have known a proof $x$ for $y$. **Thus $P^{\ast}$ isn't actually a dishonest prover, he already has a proof.**
 
-Note that the commitment $t$ is the same for the two accepting conversations. The challenge $c$ and $c'$ are chosen after the commitment, so if the prover can come up with $z$ and $z'$ so that $(t, c, z)$ and $(t, c', z')$ are accepting conversations for $y$, then the prover must have known $x$.
-
-We also require that the challenge space is large, the challenger shouldn't be accepted by luck.
+Note that the commitment $t$ is the same for the two accepting conversations. The challenges $c$ and $c'$ are chosen after the commitment, so if the prover can come up with $z$ and $z'$ so that $(t, c, z)$ and $(t, c', z')$ are accepting conversations for $y$, then the prover must have known $x$.
 
 ### Special Soundness $\implies$ Soundness
 
@@ -90,6 +88,8 @@ We also require that the challenge space is large, the challenger shouldn't be a
 
 If there were two such challenges $c, c'$, then there would be two accepting conversations for $y^{\ast}$, which are $(t^{\ast}, c, z)$ and $(t^{\ast}, c', z')$. Now by special soundness, there exists a witness $x$ for $y^{\ast}$, which is a contradiction.
 
+The challenge space must be large enough so that the challenger does not accept just by luck.
+
 ## Special Honest Verifier Zero Knowledge
 
 The conversation between $P$ and $V$ must not reveal anything.