upgrade structures and migrate to nextra v4

content/CSE442T/CSE442T_L21.md

@@ -0,0 +1,147 @@
+# Lecture 21
+
+## Chapter 5: Authentication
+
+### Digital Signature Scheme
+
+"Chain based approach".
+
+$pk_0\to m_1||pk_1\to m_2||pk_2\to m_3||pk_3\to m_4\dots$
+
+The signature size grows linearly with the message size $n$.
+
+Improvement:
+
+Use "Tree based approach".
+
+Instead of creating 1 public key, we create 2 public keys each time and use the shorter one to sign the next message.
+
+For example, let $n=4$, and we want to sign $m=1100$.
+
+Every verifier knows the public key.
+
+Then we generates $(pk_0,sk_0),(pk_1,sk_1)$ and store $\sigma, sk_0,sk_1$
+
+$\sigma=Sign_{sk_0}(pk_0||pk_1)$
+
+and generates $\to (pk_2,sk_2)\to (pk_3,sk_3)\to (pk_4,sk_4)$
+
+$\sigma_1=Sign_{sk_1}(pk_{10}||pk_{11})$
+
+$\sigma_{11}=Sign_{sk_{11}}(pk_{110}||pk_{111})$
+
+$\sigma_{110}=Sign_{sk_{110}}(pk_{1100}||pk_{1101})$
+
+$\sigma_{1100}=Sign_{sk_{1100}}(m)$
+
+So we sign $m=1100$ as $\sigma_{1100}$.
+
+The final signature is $\sigma'=(pk,\sigma,pk_1,\sigma_1,pk_{11},\sigma_{11},pk_{110},\sigma_{110},pk_{1100},\sigma_{1100})$.
+
+The verifier can verify the signature by checking the authenticity of each public key.
+
+Outputs $m,\sigma'_m$
+
+The signature size grows logarithmically with the message size $n$.
+
+If we want to sign $m=1110$ for next message, we can just append $1110$ to the end of the previous signature since $pk_1,pk_{11},pk_{110}$ are all stored in the previous signature tree.
+
+So the next signature is $\sigma'_{1110}=(pk,\sigma,pk_1,\sigma_1,pk_{11},\sigma_{11},pk_{111},\sigma_{111},pk_{1110},\sigma_{1110})$.
+
+The size of the next signature is still $O(\log n)$.
+
+Advantages:
+
+1. The signature size is small (do not grow linearly as the number of messages grows).
+2. The verification is efficient (do not need to check all the previous messages).
+3. The signature is secure.
+
+Disadvantages:
+
+1. Have to store all the public keys securely pair as you go.
+
+Fix: Psudo-randomness.
+
+Use a Pseudo-random number generator to generate random pk/sk pairs.
+
+Since the PRG is deterministic, we don't need to store the public keys anymore.
+
+We can use a random seed to generate all the pk/sk pairs.
+
+### Trapdoor-based Signature Scheme
+
+Idea: use RSA to create
+
+$N=p\cdot q$, $e\in\mathbb{Z}_{\phi(N)}^*$, $d=e^{-1}\mod\phi(N)$ (secret key)
+
+We do the "flip" encryption as follows:
+
+Let $c=Enc_{pk}(m)=m^e\mod N$
+
+Then $Dec_{sk}(c)=c^d\mod N=m'\mod N$.
+
+$\sigma=Sign_{sk}(m)=m^d\mod N$
+
+$Verify_{pk}(m,\sigma)=1\iff \sigma^e=(m^d)^e\mod N=m$
+
+#### Forgery 1: 
+
+Ask oracle nothing.
+
+Pick random $\sigma$ let $m=\sigma^e$.
+
+Although in this case, the adversary has no control over $m$, it is still not very good.
+
+#### Forgery 2:
+
+They want to sign $m$.
+
+Pick $m_1,m_2$ and $m=m_1\cdot m_2$.
+
+Ask oracle for $Enc_{pk}(m_1)=\sigma_1$ and $Enc_{pk}(m_2)=\sigma_2$.
+
+Output $\sigma=\sigma_1\cdot\sigma_2$, since $\sigma_1\cdot\sigma_2=(m_1^d\mod N)\cdot(m_2^d\mod N)=(m_1\cdot m_2)^d\mod N=m^d=\sigma$.
+
+This is a valid signature for $m$.
+
+That's very bad.
+
+This means if we signed two messages $m_1,m_2$, we can get a valid signature for $m_1\cdot m_2$. If unfortunately $m_1\cdot m_2$ is the message we want to sign, the adversary can produce a fake signature for free.
+
+#### Fix for forgeries
+
+Pick a "random"-looking function $h:\mathcal{M}\to\mathbb{Z}_N^*$. ($h(\cdot)$ is collision-resistant)
+
+$pk=(h,N,e)$, $sk=(h,N,d)$
+
+$Sign_{sk}(m)=h(m)^d\mod N$
+
+$Verify_{pk}(m,\sigma)=1\iff \sigma^e=h(m)\mod N$
+
+If $h$ is truly random, this would be secure.
+
+$\sigma^e=m$ and $\sigma^e=h(m)\cancel{\to}m$
+
+So $\sigma_1=h(m_1)^d$ and $\sigma_2=h(m_2)^d$, If $m=m_1\cdot m_2$, then $\sigma_1\cdot\sigma_2=h(m_1)^d\cdot h(m_2)^d\neq h(m)^d=\sigma$. (the equality is very unlikely to happen)
+
+This is secure.
+
+Choices of $h$:
+
+1. $h$ is random function. Not practical since we need the verifier to know $h$.
+2. $h$ is pseudo-random function. Verifier needs to use $h$, with full access to the random oracle. If we use $f_k$ for a random key $k$, they need $k$. No more pseudo-random security guarantee.
+3. $h$ is a collision-resistant hash function. We can't be sure it doesn't have any patterns like $h(m_1\cdot m_2)=h(m_1)\cdot h(m_2)$.
+
+Here we present our silly solution:
+
+#### Random oracle model:
+
+Assume we have a true random function $h$, the adversary only has oracle access to $h$.
+
+And $h$ is practical to use.
+
+This RSA scheme under the random oracle model is secure. (LOL)
+
+This requires a proof.
+
+In practice, SHA-256 is used as $h$. Fun, no one really finds a collision yet.