mirror of
https://github.com/calofmijuck/blog.git
synced 2025-12-06 22:53:51 +00:00
feat: breaking change (unstable) (#198)
* [PUBLISHER] upload files #175 * PUSH NOTE : 3. Symmetric Key Encryption.md * PUSH NOTE : 03. Symmetric Key Cryptography (2).md * DELETE FILE : _posts/lecture-notes/modern-cryptography/2023-09-18-symmetric-key-cryptography-2.md * DELETE FILE : _posts/lecture-notes/modern-cryptography/2023-09-19-symmetric-key-encryption.md * [PUBLISHER] upload files #177 * PUSH NOTE : 3. Symmetric Key Encryption.md * PUSH NOTE : 03. Symmetric Key Cryptography (2).md * DELETE FILE : _posts/lecture-notes/modern-cryptography/2023-09-18-symmetric-key-cryptography-2.md * DELETE FILE : _posts/lecture-notes/modern-cryptography/2023-09-19-symmetric-key-encryptio.md * [PUBLISHER] upload files #178 * PUSH NOTE : 3. Symmetric Key Encryption.md * PUSH NOTE : 03. Symmetric Key Cryptography (2).md * DELETE FILE : _posts/lecture-notes/modern-cryptography/2023-09-18-symmetric-key-cryptography-2.md * [PUBLISHER] upload files #179 * PUSH NOTE : 3. Symmetric Key Encryption.md * PUSH NOTE : 03. Symmetric Key Cryptography (2).md * DELETE FILE : _posts/lecture-notes/modern-cryptography/2023-09-18-symmetric-key-cryptography-2.md * [PUBLISHER] upload files #180 * PUSH NOTE : 3. Symmetric Key Encryption.md * PUSH NOTE : 03. Symmetric Key Cryptography (2).md * DELETE FILE : _posts/lecture-notes/modern-cryptography/2023-09-18-symmetric-key-cryptography-2.md * [PUBLISHER] upload files #181 * PUSH NOTE : 3. Symmetric Key Encryption.md * PUSH NOTE : 03. Symmetric Key Cryptography (2).md * DELETE FILE : _posts/lecture-notes/modern-cryptography/2023-09-18-symmetric-key-cryptography-2.md * [PUBLISHER] upload files #182 * PUSH NOTE : 3. Symmetric Key Encryption.md * PUSH NOTE : 03. Symmetric Key Cryptography (2).md * [PUBLISHER] upload files #183 * PUSH NOTE : 3. Symmetric Key Encryption.md * PUSH NOTE : 03. Symmetric Key Cryptography (2).md * DELETE FILE : _posts/lecture-notes/modern-cryptography/2023-09-18-symmetric-key-cryptography-2.md * [PUBLISHER] upload files #184 * PUSH NOTE : 3. Symmetric Key Encryption.md * PUSH NOTE : 03. Symmetric Key Cryptography (2).md * DELETE FILE : _posts/lecture-notes/modern-cryptography/2023-09-18-symmetric-key-cryptography-2.md * [PUBLISHER] upload files #185 * PUSH NOTE : 3. Symmetric Key Encryption.md * PUSH NOTE : 03. Symmetric Key Cryptography (2).md * DELETE FILE : _posts/lecture-notes/modern-cryptography/2023-09-18-symmetric-key-cryptography-2.md * [PUBLISHER] upload files #186 * PUSH NOTE : 3. Symmetric Key Encryption.md * PUSH NOTE : 03. Symmetric Key Cryptography (2).md * [PUBLISHER] upload files #187 * PUSH NOTE : 3. Symmetric Key Encryption.md * PUSH NOTE : 14. Secure Multiparty Computation.md * DELETE FILE : _posts/Lecture Notes/Modern Cryptography/2023-09-19-symmetric-key-encryption.md * DELETE FILE : _posts/lecture-notes/modern-cryptography/2023-09-18-symmetric-key-cryptography-2.md * [PUBLISHER] upload files #188 * PUSH NOTE : 3. Symmetric Key Encryption.md * PUSH NOTE : 14. Secure Multiparty Computation.md * DELETE FILE : _posts/Lecture Notes/Modern Cryptography/2023-09-19-symmetric-key-encryption.md * chore: remove files * [PUBLISHER] upload files #197 * PUSH NOTE : 수학 공부에 대한 고찰.md * PUSH NOTE : 09. Lp Functions.md * PUSH ATTACHMENT : mt-09.png * PUSH NOTE : 08. Comparison with the Riemann Integral.md * PUSH ATTACHMENT : mt-08.png * PUSH NOTE : 04. Measurable Functions.md * PUSH ATTACHMENT : mt-04.png * PUSH NOTE : 06. Convergence Theorems.md * PUSH ATTACHMENT : mt-06.png * PUSH NOTE : 07. Dominated Convergence Theorem.md * PUSH ATTACHMENT : mt-07.png * PUSH NOTE : 05. Lebesgue Integration.md * PUSH ATTACHMENT : mt-05.png * PUSH NOTE : 03. Measure Spaces.md * PUSH ATTACHMENT : mt-03.png * PUSH NOTE : 02. Construction of Measure.md * PUSH ATTACHMENT : mt-02.png * PUSH NOTE : 01. Algebra of Sets and Set Functions.md * PUSH ATTACHMENT : mt-01.png * PUSH NOTE : Rules of Inference with Coq.md * PUSH NOTE : 블로그 이주 이야기.md * PUSH NOTE : Secure IAM on AWS with Multi-Account Strategy.md * PUSH ATTACHMENT : separation-by-product.png * PUSH NOTE : You and Your Research, Richard Hamming.md * PUSH NOTE : 10. Digital Signatures.md * PUSH ATTACHMENT : mc-10-dsig-security.png * PUSH ATTACHMENT : mc-10-schnorr-identification.png * PUSH NOTE : 9. Public Key Encryption.md * PUSH ATTACHMENT : mc-09-ss-pke.png * PUSH NOTE : 8. Number Theory.md * 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 : 1. OTP, Stream Ciphers and PRGs.md * PUSH ATTACHMENT : mc-01-prg-game.png * PUSH ATTACHMENT : mc-01-ss.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 : 3. Symmetric Key Encryption.md * PUSH ATTACHMENT : is-03-ecb-encryption.png * PUSH ATTACHMENT : is-03-cbc-encryption.png * PUSH ATTACHMENT : is-03-ctr-encryption.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 : 18. Bootstrapping & CKKS.md * PUSH NOTE : 17. BGV Scheme.md * PUSH NOTE : 16. The GMW Protocol.md * PUSH ATTACHMENT : mc-16-beaver-triple.png * PUSH NOTE : 15. Garbled Circuits.md * PUSH NOTE : 14. Secure Multiparty Computation.md * PUSH NOTE : 13. Sigma Protocols.md * PUSH ATTACHMENT : mc-13-sigma-protocol.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 : 11. Advanced Topics.md * PUSH NOTE : 0. Introduction.md * PUSH NOTE : 02. Symmetric Key Cryptography (1).md * 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 : 03. Symmetric Key Cryptography (2).md * PUSH ATTACHMENT : is-03-feistel-function.png * PUSH ATTACHMENT : is-03-cfb-encryption.png * PUSH ATTACHMENT : is-03-ofb-encryption.png * PUSH NOTE : 04. Modular Arithmetic (1).md * PUSH NOTE : 01. Security Introduction.md * PUSH ATTACHMENT : is-01-cryptosystem.png * PUSH NOTE : Search Time in Hash Tables.md * PUSH NOTE : 랜덤 PS일지 (1).md * chore: rearrange articles * feat: fix paths * feat: fix all broken links * feat: title font to palatino
This commit is contained in:
@@ -22,10 +22,10 @@ attachment:
|
||||
## Digital Signatures
|
||||
|
||||
> **Definition.** A **signature scheme** $\mc{S} = (G, S, V)$ is a triple of efficient algorithms, where $G$ is a **key generation** algorithm, $S$ is a **signing** algorithm, and $V$ is a **verification** algorithm.
|
||||
>
|
||||
>
|
||||
> - A probabilistic algorithm $G$ outputs a pair $(pk, sk)$, where $sk$ is called a secret **signing key**, and $pk$ is a public **verification key**.
|
||||
> - Given $sk$ and a message $m$, a probabilistic algorithm $S$ outputs a **signature** $\sigma \la S(sk, m)$.
|
||||
> - $V$ is a deterministic algorithm that outputs either $\texttt{{accept}}$ or $\texttt{reject}$ for $V(pk, m, \sigma)$.
|
||||
> - $V$ is a deterministic algorithm that outputs either $\texttt{accept}$ or $\texttt{reject}$ for $V(pk, m, \sigma)$.
|
||||
|
||||
The correctness property requires that all signatures generated by $S$ is always accepted by $V$. For all $(pk, sk) \la G$ and $m \in \mc{M}$,
|
||||
|
||||
@@ -60,20 +60,20 @@ The definition is similar to the [secure MAC](../2023-09-21-macs/#secure-mac-unf
|
||||

|
||||
|
||||
> **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.
|
||||
>
|
||||
>
|
||||
> 1. The challenger generates $(pk, sk) \la G()$ and sends $pk$ to $\mc{A}$.
|
||||
> 2. $\mc{A}$ makes a series of *signing queries* to the challenger.
|
||||
> - Each query is a message $m_i \in \mc{M}$, the challenger responds with $\sigma_i \la S(sk, m_i)$.
|
||||
> - Each query is a message $m _ i \in \mc{M}$, the challenger responds with $\sigma _ i \la S(sk, m _ i)$.
|
||||
> 3. $\mc{A}$ computes and outputs a candidate forgery pair $(m, \sigma) \in \mc{M} \times \Sigma$.
|
||||
> - $m \notin \left\lbrace m_1, \dots, m_q \right\rbrace$.
|
||||
> - $(m, \sigma) \notin \left\lbrace (m_1, \sigma_1), \dots, (m_q, \sigma_q) \right\rbrace$. (strong)
|
||||
>
|
||||
> - $m \notin \left\lbrace m _ 1, \dots, m _ q \right\rbrace$.
|
||||
> - $(m, \sigma) \notin \left\lbrace (m _ 1, \sigma _ 1), \dots, (m _ q, \sigma _ q) \right\rbrace$. (strong)
|
||||
>
|
||||
> $\mc{A}$ wins if $V(pk, m, \sigma) = \texttt{accept}$, let this event be $W$. The advantage of $\mc{A}$ with respect to $\mc{S}$ is defined as
|
||||
>
|
||||
>
|
||||
> $$
|
||||
> \rm{Adv}_{\rm{SIG}}[\mc{A}, \mc{S}] = \Pr[W].
|
||||
> \rm{Adv} _ {\rm{SIG}}[\mc{A}, \mc{S}] = \Pr[W].
|
||||
> $$
|
||||
>
|
||||
>
|
||||
> If the advantage is negligible for all efficient adversaries $\mc{A}$, the signature scheme $S$ is (strongly) **secure**. $\mc{S}$ is **existentially unforgeable under a chosen message attack**.
|
||||
|
||||
- We do not make verification queries, since the adversary can always check any signature.
|
||||
@@ -108,11 +108,11 @@ $$
|
||||
This is often called the **hash-and-sign paradigm**, and the new signature scheme is also secure.
|
||||
|
||||
> **Theorem.** Suppose that $\mc{S}$ is a secure signature scheme and $H$ is a collision resistant hash function. Then $\mc{S}'$ is a secure signature.
|
||||
>
|
||||
> If $\mc{A}$ is an adversary attacking $\mc{S}'$, then there exist an adversary $\mc{B}_\mc{S}$ attacking $\mc{S}$ and an adversary $\mc{B}_H$ attacking $H$ such that
|
||||
>
|
||||
>
|
||||
> If $\mc{A}$ is an adversary attacking $\mc{S}'$, then there exist an adversary $\mc{B} _ \mc{S}$ attacking $\mc{S}$ and an adversary $\mc{B} _ H$ attacking $H$ such that
|
||||
>
|
||||
> $$
|
||||
> \rm{Adv}_{\rm{SIG}}[A, \mc{S}'] \leq \rm{Adv}_{\rm{SIG}}[\mc{B}_\mc{S}, \mc{S}] + \rm{Adv}_{\rm{CR}}[\mc{B}_H, H].
|
||||
> \rm{Adv} _ {\rm{SIG}}[A, \mc{S}'] \leq \rm{Adv} _ {\rm{SIG}}[\mc{B} _ \mc{S}, \mc{S}] + \rm{Adv} _ {\rm{CR}}[\mc{B} _ H, H].
|
||||
> $$
|
||||
|
||||
*Proof*. The proof is identical to the theorem for MACs.
|
||||
@@ -135,16 +135,16 @@ Here are some possible attacks.
|
||||
- Just return $(\sigma^e, \sigma)$ for some $\sigma$. Then it passes verification.
|
||||
- Attack using the homomorphic property.
|
||||
- Suppose we want to forge a message $m$.
|
||||
- Pick $m_1 \in \Z_N^{\ast}$ and set $m_2 = m\cdot m_1^{-1} \bmod N$.
|
||||
- Pick $m _ 1 \in \Z _ N^{\ast}$ and set $m _ 2 = m\cdot m _ 1^{-1} \bmod N$.
|
||||
- Query signatures for both messages and multiply the responses.
|
||||
- $\sigma = \sigma_1 \cdot \sigma_2 = m_1^e \cdot m^e \cdot m_1^{-e} = m^e \bmod N$.
|
||||
- $\sigma = \sigma _ 1 \cdot \sigma _ 2 = m _ 1^e \cdot m^e \cdot m _ 1^{-e} = m^e \bmod N$.
|
||||
- Then $(m, \sigma)$ is a valid pair.
|
||||
|
||||
Because of the second attack, the textbook RSA signature is **universally forgeable**. This property is used to create **blind signatures**, where the signer creates a signature without any knowledge about the message. See Exercise 13.15.[^1]
|
||||
|
||||
### RSA Full Domain Hash Signature Scheme
|
||||
|
||||
Given a hash function $H : \mc{M} \ra \mc{Y}$, the **RSA full domain hash** signature scheme $\mc{S}_\rm{RSA-FDH}$ is defined as follows.
|
||||
Given a hash function $H : \mc{M} \ra \mc{Y}$, the **RSA full domain hash** signature scheme $\mc{S} _ \rm{RSA-FDH}$ is defined as follows.
|
||||
|
||||
- Key generation: $pk = (N, e)$ and $sk = (N, d)$ are chosen to satisfy $d = e^{-1} \bmod \phi(N)$ for $N = pq$.
|
||||
- Sign: $S(sk, m) = H(m)^d \bmod N$.
|
||||
@@ -152,25 +152,25 @@ Given a hash function $H : \mc{M} \ra \mc{Y}$, the **RSA full domain hash** sign
|
||||
|
||||
This scheme is now secure.
|
||||
|
||||
> **Theorem.** If the hash function $H$ is modeled as a random oracle, and the RSA assumptions holds, then $\mc{S}_\rm{RSA-FDH}$ is a secure signature scheme.
|
||||
>
|
||||
> **Theorem.** If the hash function $H$ is modeled as a random oracle, and the RSA assumptions holds, then $\mc{S} _ \rm{RSA-FDH}$ is a secure signature scheme.
|
||||
>
|
||||
> For any $q$-query adversary $\mc{A}$ against hashed RSA, there exists an adversary $\mc{B}$ solving the RSA problem such that
|
||||
>
|
||||
>
|
||||
> $$
|
||||
> \rm{Adv}_{\rm{SIG}}[\mc{A}, \mc{S}_\rm{RSA-FDH}] \leq q \cdot \rm{Adv}_{\rm{RSA}}[\mc{B}].
|
||||
> \rm{Adv} _ {\rm{SIG}}[\mc{A}, \mc{S} _ \rm{RSA-FDH}] \leq q \cdot \rm{Adv} _ {\rm{RSA}}[\mc{B}].
|
||||
> $$
|
||||
|
||||
### Full Domain Hash Signature Scheme
|
||||
|
||||
The following is a description of a **full domain hash** scheme $\mc{S}_\rm{FDH}$, constructed from trapdoor permutation scheme $\mc{T} = (G, F, I)$.
|
||||
The following is a description of a **full domain hash** scheme $\mc{S} _ \rm{FDH}$, constructed from trapdoor permutation scheme $\mc{T} = (G, F, I)$.
|
||||
|
||||
- Key generation: $(pk, sk) \la G()$.
|
||||
- Sign: $S(sk, m)$ returns $\sigma \la I(sk, H(m))$.
|
||||
- Verify: $V(pk, m, \sigma)$ returns $\texttt{accept}$ if and only if $F(pk, \sigma) = H(m)$.
|
||||
|
||||
This scheme $\mc{S}_\rm{FDH} = (G, S, V)$ is secure if $\mc{T}$ is a **one-way trapdoor permutation** and $H$ is a random oracle.
|
||||
This scheme $\mc{S} _ \rm{FDH} = (G, S, V)$ is secure if $\mc{T}$ is a **one-way trapdoor permutation** and $H$ is a random oracle.
|
||||
|
||||
> **Theorem.** Let $\mc{T} = (G,F,I)$ be a one-way trapdoor permutation defined over $\mc{X}$. Let $H : \mc{M} \ra \mc{X}$ be a hash function, modeled as a random oracle. Then the derived FDH signature scheme $\mc{S}_\rm{FDH}$ is a secure signature scheme.
|
||||
> **Theorem.** Let $\mc{T} = (G,F,I)$ be a one-way trapdoor permutation defined over $\mc{X}$. Let $H : \mc{M} \ra \mc{X}$ be a hash function, modeled as a random oracle. Then the derived FDH signature scheme $\mc{S} _ \rm{FDH}$ is a secure signature scheme.
|
||||
|
||||
*Proof*. See Theorem 13.3.[^1]
|
||||
|
||||
@@ -182,26 +182,26 @@ This one uses discrete logarithms.
|
||||
|
||||
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$**.
|
||||
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.
|
||||
The protocol $\mc{I} _ \rm{sch} = (G, P, V)$ works as follows.
|
||||
|
||||
> 1. A **secret key** $\alpha \la \Z_q$ and **verification key** $u \la g^\alpha$ is generated. The prover $P$ has $\alpha$ and the verifier $V$ has $u$.
|
||||
> 2. $P$ computes a random $\alpha_t \la \Z_q$, and sends $u_t \la g^{\alpha_t}$ to $V$.
|
||||
> 3. $V$ chooses a random $c \la \Z_q$ and sends it to $P$.
|
||||
> 4. $P$ computes $\alpha_z \la \alpha_t + \alpha c \in \Z_q$ and sends it to $V$.
|
||||
> 5. $V$ checks if $g^{\alpha_z} = u_t \cdot u^c$. Accept if and only if it is equal.
|
||||
> 1. A **secret key** $\alpha \la \Z _ q$ and **verification key** $u \la g^\alpha$ is generated. The prover $P$ has $\alpha$ and the verifier $V$ has $u$.
|
||||
> 2. $P$ computes a random $\alpha _ t \la \Z _ q$, and sends $u _ t \la g^{\alpha _ t}$ to $V$.
|
||||
> 3. $V$ chooses a random $c \la \Z _ q$ and sends it to $P$.
|
||||
> 4. $P$ computes $\alpha _ z \la \alpha _ t + \alpha c \in \Z _ q$ and sends it to $V$.
|
||||
> 5. $V$ checks if $g^{\alpha _ z} = u _ t \cdot u^c$. Accept if and only if it is equal.
|
||||
|
||||
- $u_t$ is the **commitment** sent to the verifier.
|
||||
- $u _ t$ is the **commitment** sent to the verifier.
|
||||
- $c$ is the **challenge** sent to the prover.
|
||||
- If $P$ can predict the challenge, $P$ can choose $\alpha_t$ and $\alpha_z$ so that verifier accepts it.
|
||||
- $\alpha_z$ is the **response** sent to the verifier.
|
||||
- If $P$ can predict the challenge, $P$ can choose $\alpha _ t$ and $\alpha _ z$ so that verifier accepts it.
|
||||
- $\alpha _ z$ is the **response** sent to the verifier.
|
||||
|
||||
We must check a few things.
|
||||
|
||||
- **Correctness**: If $P$ has the correct $\alpha$, then $g^{\alpha_z} = g^{\alpha_t} \cdot (g^\alpha)^c = u_t \cdot u^c$.
|
||||
- **Correctness**: If $P$ has the correct $\alpha$, then $g^{\alpha _ z} = g^{\alpha _ t} \cdot (g^\alpha)^c = u _ t \cdot u^c$.
|
||||
- **Soundness**: If $P$ does not have the correct $\alpha$, it is reject with probability $1 - \frac{1}{q}$.
|
||||
- We can repeat this many times then the probability of reject is $1 - \frac{1}{q^n} \ra 1$.
|
||||
- Thus $q$ (the size of the challenge space) must be large.
|
||||
@@ -214,32 +214,32 @@ We must check a few things.
|
||||
|
||||
We *transform* the above protocol to a signature scheme.[^2] We need a hash function $H : \mc{M} \times G \ra \mc{C}$, modeled as a random oracle. The protocol originally involves interaction between two parties, but a signature is computed by a single party. Intuitively, $H$ will play the role of the verifier.
|
||||
|
||||
The **Schnorr signature scheme** $\mc{S}_\rm{sch} = (G, S, V)$ is defined as follows.
|
||||
The **Schnorr signature scheme** $\mc{S} _ \rm{sch} = (G, S, V)$ is defined as follows.
|
||||
|
||||
- Key generation: a **secret key** $sk = \alpha \la \Z_q$ and **public key** $pk = u \la g^\alpha$ is generated.
|
||||
- Sign: $S(sk, m)$ outputs $\sigma = (u_t, \alpha_z)$ where
|
||||
- Choose random $\alpha_t \la \Z_q$ and set $u_t \la g^{\alpha_t}$.
|
||||
- **Compute $c \la H(m, u_t)$** and set $\alpha_z \la \alpha_t + \alpha c$.
|
||||
- Verify: $V(pk, m, \sigma)$ outputs $\texttt{accept}$ if and only if $g^{\alpha_z} = u_t \cdot u^c$.
|
||||
- $c \la H(m, u_t)$ can be computed and $u$ is known.
|
||||
- Key generation: a **secret key** $sk = \alpha \la \Z _ q$ and **public key** $pk = u \la g^\alpha$ is generated.
|
||||
- Sign: $S(sk, m)$ outputs $\sigma = (u _ t, \alpha _ z)$ where
|
||||
- Choose random $\alpha _ t \la \Z _ q$ and set $u _ t \la g^{\alpha _ t}$.
|
||||
- **Compute $c \la H(m, u _ t)$** and set $\alpha _ z \la \alpha _ t + \alpha c$.
|
||||
- Verify: $V(pk, m, \sigma)$ outputs $\texttt{accept}$ if and only if $g^{\alpha _ z} = u _ t \cdot u^c$.
|
||||
- $c \la H(m, u _ t)$ can be computed and $u$ is known.
|
||||
|
||||
Since $H$ is being modeled as a random oracle, the signer cannot predict the value of the challenge $c$. Also, $c$ must take both $m$ and $u_t$ as input, since without $m$, the signature is not related to $m$ (the signature has no $m$ term inside it). On the other hand, without $u_t$, then the scheme is insecure since the Schnorr identification protocol is HVZK. See Exercise 19.12.[^1]
|
||||
Since $H$ is being modeled as a random oracle, the signer cannot predict the value of the challenge $c$. Also, $c$ must take both $m$ and $u _ t$ as input, since without $m$, the signature is not related to $m$ (the signature has no $m$ term inside it). On the other hand, without $u _ t$, then the scheme is insecure since the Schnorr identification protocol is HVZK. See Exercise 19.12.[^1]
|
||||
|
||||
> **Theorem.** If $H$ is modeled as a random oracle and Schnorr's identification protocol is secure, then Schnorr's signature scheme is also secure.
|
||||
|
||||
*Proof*. See Theorem 19.7.[^1]
|
||||
|
||||
Note that $\alpha \la \Z_q$ must be chosen randomly every time.
|
||||
Note that $\alpha \la \Z _ q$ must be chosen randomly every time.
|
||||
|
||||
## Digital Signature Algorithm
|
||||
|
||||
Schnorr's scheme was protected by a patent, so NIST opted for a ad-hoc signature scheme based on a prime order subgroup of $\Z_p^{\ast}$. This algorithm eventually became the **Digital Signature Algorithm** (DSA). The standard was updated to support elliptic curve groups over a finite field, resulting in **ECDSA**.
|
||||
Schnorr's scheme was protected by a patent, so NIST opted for a ad-hoc signature scheme based on a prime order subgroup of $\Z _ p^{\ast}$. This algorithm eventually became the **Digital Signature Algorithm** (DSA). The standard was updated to support elliptic curve groups over a finite field, resulting in **ECDSA**.
|
||||
|
||||
## Public Key Infrastructure
|
||||
|
||||
How would you trust public keys? We introduce **digital certificates** for this.
|
||||
|
||||
Read in [public key infrastructure (Internet Security)](../../internet-security/2023-10-16-pki).
|
||||
Read in [public key infrastructure (Internet Security)](../../internet-security/2023-10-16-pki/).
|
||||
|
||||
[^1]: A Graduate Course in Applied Cryptography
|
||||
[^2]: By using the [Fiat-Shamir transform](../2023-11-07-sigma-protocols/#the-fiat-shamir-transform).
|
||||
|
||||
Reference in New Issue
Block a user