From 08531d20b74903e9ff270f03cf5b332997398545 Mon Sep 17 00:00:00 2001 From: Zheyuan Wu <60459821+Trance-0@users.noreply.github.com> Date: Wed, 20 Nov 2024 18:19:40 -0600 Subject: [PATCH] update notes --- pages/CSE347/index.md | 21 +++++ pages/CSE347/index.mdx | 1 - pages/CSE442T/CSE442T_L21.md | 148 ++++++++++++++++++++++++++++++++++- 3 files changed, 168 insertions(+), 2 deletions(-) create mode 100644 pages/CSE347/index.md delete mode 100644 pages/CSE347/index.mdx diff --git a/pages/CSE347/index.md b/pages/CSE347/index.md new file mode 100644 index 0000000..f31bdd9 --- /dev/null +++ b/pages/CSE347/index.md @@ -0,0 +1,21 @@ +# CSE 347 + +This is a course about fancy algorithms. + +Topics include: + +1. Greedy Algorithms +2. Dynamic Programming +3. Divide and Conquer +4. Maximum Flows +5. Reductions +6. NP-Complete Problems +7. Approximation Algorithms +8. Randomized Algorithms +9. Online Algorithms + +It's hard if you don't know the tricks for solving leetcode problems. + +I've been doing leetcode daily problems for almost 2 years when I get into the course. + +It's relatively easy for me but I do have a hard time to get every proof right. \ No newline at end of file diff --git a/pages/CSE347/index.mdx b/pages/CSE347/index.mdx deleted file mode 100644 index 21e60f8..0000000 --- a/pages/CSE347/index.mdx +++ /dev/null @@ -1 +0,0 @@ -# Test \ No newline at end of file diff --git a/pages/CSE442T/CSE442T_L21.md b/pages/CSE442T/CSE442T_L21.md index 9ce48b9..1d7e1a8 100644 --- a/pages/CSE442T/CSE442T_L21.md +++ b/pages/CSE442T/CSE442T_L21.md @@ -1 +1,147 @@ -# Lecture 21 \ No newline at end of file +# Lecture 21 + +## 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.