密码学题型as2en

Task F: Schnorr Protocol Security Analysis

Problem Analysis

Problem Background and Core Challenges

Task F provides an in-depth analysis of the Schnorr Identification Protocol, a standard zero-knowledge Sigma protocol. The goal of this protocol is to prove that the Prover knows the discrete logarithm $x$ such that the public key $y = g^x$.

This problem analyzes the security of the protocol from three perspectives:

1. Lack of Soundness: When the verifier's random number generator is predictable, a malicious prover can pass verification through a "lucky guess" attack
2. Special Soundness: Through "rewinding" techniques, we can formally prove knowledge soundness
3. Real-World Implementation Errors: When the prover reuses the random number $k$, an attacker can recover the secret key

Basic Structure of the Schnorr Protocol

Public Parameters:

• Group $G$: A group of large prime order $q$ with generator $g$

Keys:

• Secret Key (Prover): $x \in \mathbb{Z}_q$
• Public Key (Verifier): $y = g^x$

Protocol Steps (P ↔ V):

1. Commit: P selects random $k \in \mathbb{Z}_q$, computes commitment $t = g^k$, and sends $t$ to V
2. Challenge: V selects random challenge $c \in \mathbb{Z}_q$ and sends $c$ to P
3. Response: P computes response $z = k + c \cdot x \pmod{q}$ and sends $z$ to V
4. Verify: V accepts the proof if and only if the check $g^z \equiv t \cdot y^c$ holds

Correctness Verification: $g^z = g^{k + cx} = g^k \cdot g^{cx} = g^k \cdot (g^x)^c = t \cdot y^c \quad \checkmark$

Three Basic Properties of Zero-Knowledge Proofs

1. Completeness: If the prover knows the secret, an honest verifier always accepts
2. Soundness: If the prover does not know the secret, the verifier rejects with high probability
3. Zero-Knowledge: The verifier cannot obtain any information about the secret from the proof process

---

Problem 1.1: "Lucky Guess" Attack (Lack of Soundness)

Problem Description

Scenario: Malicious prover Mallory does not know the secret $x$, but she knows that the verifier's random number generator is weak and always issues the challenge value $c$ (predictable).

Question (a): Show how Mallory can construct a valid proof transcript $(t, c, z)$ that passes the verification check $g^z = t \cdot y^c$ without knowing $x$. Clearly state the order in which Mallory generates $z$ and $t$.

Question (b): Explain why this "lucky guess" attack works in a single interaction.

In-Depth Analysis

Definition of Soundness

Soundness:

• If the prover does not know the secret, the verifier rejects the proof with high probability
• Formal: $\Pr[\text{Verifier accepts} | \text{Prover doesn't know secret}] \leq \epsilon$, where $\epsilon$ is a negligible function

Importance of Soundness:

• Ensures that provers without the secret cannot pass verification
• If Soundness is not satisfied, the protocol is insecure

The Problem of Predictable Challenges

Normal Case:

• The verifier randomly selects challenge $c$, which the prover cannot predict
• The prover must choose $t$ in advance, then compute $z$ based on $c$
• Without knowing $x$, it is impossible to compute the correct $z$ for any arbitrary $c$

Case of Predictable Challenge:

• If challenge $c$ is predictable (e.g., always a fixed value or can be inferred from some information)
• The prover can know $c$ in advance and thus construct a valid proof

Standard Answer

Question (a): Mallory's Attack Method

Mallory's Knowledge:

• Mallory does not know the secret $x$
• Mallory knows that the verifier's random number generator is weak and always issues challenge value $c$ (predictable)

Mallory's Attack Steps:

Step 1: Mallory knows challenge $c$ in advance

• Since the verifier's random number generator is predictable, Mallory can know the challenge value $c$ in advance

Step 2: Mallory randomly selects response $z$

• Mallory randomly selects $z \leftarrow \mathbb{Z}_q$

Step 3: Mallory computes commitment $t$

• Mallory computes: $t = g^z \cdot y^{-c}$
• This is equivalent to: $t = g^z \cdot (g^x)^{-c} = g^z \cdot g^{-cx} = g^{z-cx}$

Step 4: Mallory sends $(t, c, z)$ to the verifier

Verification Check: $g^z = t \cdot y^c = (g^z \cdot y^{-c}) \cdot y^c = g^z \cdot y^{-c} \cdot y^c = g^z \quad \checkmark$

Key Observation:

• Generation Order: Mallory first selects $z$, then computes $t$
• This is opposite to the normal protocol: the normal protocol first selects $k$ (thus determining $t$), then computes $z$ based on $c$
• Since Mallory knows $c$ in advance, she can "work backwards": first select $z$, then compute $t$ that makes the verification equation hold

Question (b): Why the "Lucky Guess" Attack Works in a Single Interaction

Philosophical Reasons:

1. Soundness Depends on Challenge Unpredictability:

   • The proof of Soundness relies on the prover's inability to predict the challenge
   • If the challenge is predictable, the prover can "prepare in advance"

2. Limitations of Single Interaction:

   • In a single interaction, the verifier only sends the challenge once
   • If the challenge is predictable, the prover can construct a valid proof for this specific challenge
   • The verifier cannot "retry" to detect whether the prover really knows the secret

3. Possibility of "Working Backwards":

   • Normal protocol: $t = g^k$ (determined first), $z = k + cx$ (computed later)
   • Attack method: $z$ (selected first), $t = g^z \cdot y^{-c}$ (computed later)
   • Since $c$ is known, we can "work backwards" to find $t$ that makes the verification equation hold

4. Lack of "Knowledge Extraction" Mechanism:

   • In a single interaction, the verifier cannot extract the prover's knowledge
   • If the challenge is predictable, the prover can "forge" a knowledge proof without really knowing the secret

Summary: The "lucky guess" attack works in a single interaction because Soundness depends on the randomness and unpredictability of the challenge. When the challenge is predictable, the prover can construct a valid proof for a specific challenge without knowing the secret.

---

Problem 1.2: The Rewinding Trap (Special Soundness)

Problem Description

Scenario: To formally prove "Knowledge Soundness", we use a "thought experiment" involving an "Extractor" capable of "rewinding" the prover. The purpose of this test is to ensure the prover is not just "getting lucky".

Scenario Description:

• A malicious prover is tested by the "rewinding" process
• The prover outputs commitment $t$
• Then is forced to correctly answer two different challenges

Run A: Challenge $c_1$ yields valid response $z_1$ Run B: Challenge $c_2$ yields valid response $z_2$ (where $c_1 \neq c_2$)

Since $t$ is the same in both runs, this means the hidden random number $k$ (such that $t = g^k$) is also the same.

Question (a): Write down the two verification equations based on the prover's knowledge for Run A and Run B.

Question (b): Using algebraic manipulation (subtraction and modular arithmetic), prove that the Extractor can compute the secret $x$ using only the public values $z_1, z_2, c_1, c_2$. Derive the formula for $x$.

Question (c): Explain, in a single sentence, why this Rewinding process guarantees that any prover who can consistently pass this test must possess the secret $x$.

In-Depth Analysis

Concept of Special Soundness

Special Soundness:

• If a prover can answer two different challenges $c_1 \neq c_2$ for the same commitment $t$, then the secret can be extracted
• This is a stronger property than ordinary Soundness: it not only ensures that provers without the secret cannot pass verification, but also guarantees that provers who can pass verification must know the secret (knowledge extraction)

Rewinding Technique

Rewinding Technique:

• The extractor can "rewind" the prover, using the same commitment $t$ but sending different challenges
• If the prover can provide valid responses to two different challenges, the secret can be extracted from the two responses

Why Rewinding is Needed:

• In a single interaction, the secret cannot be extracted
• Through rewinding, we can "force" the prover to answer multiple challenges, thus extracting the secret

Standard Answer

Question (a): Two Verification Equations

Run A:

• Commitment: $t = g^k$
• Challenge: $c_1$
• Response: $z_1 = k + c_1 \cdot x \pmod{q}$
• Verification equation: $g^{z_1} = t \cdot y^{c_1}$

Run B:

• Commitment: $t = g^k$ (same as Run A)
• Challenge: $c_2$ ($c_2 \neq c_1$)
• Response: $z_2 = k + c_2 \cdot x \pmod{q}$
• Verification equation: $g^{z_2} = t \cdot y^{c_2}$

Key Observation:

• Both runs use the same $t$ and $k$
• But challenges are different: $c_1 \neq c_2$
• Responses are also different: $z_1 \neq z_2$

Question (b): Derivation of Formula to Extract Secret $x$

Given Conditions:

• $z_1 = k + c_1 \cdot x \pmod{q}$
• $z_2 = k + c_2 \cdot x \pmod{q}$
• $c_1 \neq c_2$

Derivation Process:

Step 1: Compute $z_1 - z_2$ $z_1 - z_2 = (k + c_1 \cdot x) - (k + c_2 \cdot x) = c_1 \cdot x - c_2 \cdot x = (c_1 - c_2) \cdot x \pmod{q}$

Step 2: Solve for $x$ Since $c_1 \neq c_2$, $c_1 - c_2 \neq 0$, therefore $(c_1 - c_2)$ has an inverse in $\mathbb{Z}_q$.

$x = (z_1 - z_2) \cdot (c_1 - c_2)^{-1} \pmod{q}$

Verification: $x = \frac{z_1 - z_2}{c_1 - c_2} \pmod{q}$

Extractor's Algorithm:

1. Run the protocol, obtain $(t, c_1, z_1)$
2. Rewind the protocol, use the same $t$, send different challenge $c_2$, obtain $(t, c_2, z_2)$
3. Compute: $x = (z_1 - z_2) \cdot (c_1 - c_2)^{-1} \pmod{q}$

Key Observation:

• The extractor only needs public values: $z_1, z_2, c_1, c_2$
• Does not need to know $k$ (because $k$ is eliminated in the subtraction)
• As long as $c_1 \neq c_2$, $x$ can be computed

Question (c): Why Rewinding Guarantees the Prover Must Possess Secret $x$

One-Sentence Explanation:

If a prover can answer two different challenges $c_1 \neq c_2$ for the same commitment $t$, then the secret $x = (z_1 - z_2) \cdot (c_1 - c_2)^{-1} \pmod{q}$ can be directly computed from the two responses $z_1, z_2$, which means the prover must know $x$ (or be able to compute $x$), otherwise it cannot construct responses that satisfy both verification equations.

Detailed Explanation:

1. Possibility of Knowledge Extraction:

   • If the prover can pass the rewinding test, the extractor can compute $x$
   • This means the prover "possesses" the knowledge (or can compute the knowledge)

2. Impossibility Argument:

   • If the prover does not know $x$, it cannot provide correct responses to arbitrary challenges
   • Even if "lucky" to pass verification once, it cannot provide correct responses to a second different challenge
   • Therefore, a prover who can pass the rewinding test must know $x$

3. Guarantee of Special Soundness:

   • Special Soundness guarantees: provers who can pass verification have extractable knowledge
   • This is stronger than ordinary Soundness: it not only ensures that provers without the secret cannot pass, but also guarantees that provers who can pass must know the secret

---

Problem 1.3: Real-World Implementation Error (Nonce Reuse)

Problem Description

Scenario: The mathematical extraction proved in Question 1.2 is highly theoretical. However, sometimes a disastrous real-world implementation error causes the exact same extraction to occur naturally.

Consider a lazy prover Peggy who reuses the same random value $k$ (and thus the same commitment $t$) for two separate, independent proofs against different challenges $c_1$ and $c_2$. An attacker Eve observes two complete transcripts:

• Transcript 1: $(t, c_1, z_1)$
• Transcript 2: $(t, c_2, z_2)$

Question (a): Prove that Eve can recover Peggy's secret key $x$ using the same algebraic method as in Question 1.2, without needing to "hack" or "rewind time".

Question (b): Explain the difference in who controls the reuse of $k$ in the following two scenarios, and why one is a feature (Soundness Proof) and the other is a fatal bug (Real-World Attack):

• Scenario A: The Extractor forcing $k$ reuse in Question 1.2
• Scenario B: The Prover accidentally reusing $k$ in this Question

In-Depth Analysis

Danger of Nonce Reuse

Role of Nonce (Random Number):

• In the Schnorr protocol, $k$ is a random number (nonce) used to generate commitment $t = g^k$
• $k$ must be randomly chosen each time and cannot be reused

Consequences of Nonce Reuse:

• If $k$ is reused, two different proofs use the same $t$
• An attacker can observe two transcripts and thus extract the secret

Theoretical Extraction vs. Real-World Attack

Theoretical Extraction (Problem 1.2):

• The extractor can "rewind" the prover, forcing the use of the same $t$
• This is a theoretical thought experiment used to prove Special Soundness

Real-World Attack (Problem 1.3):

• The prover herself reuses $k$, causing two proofs to use the same $t$
• An attacker only needs to observe two transcripts to extract the secret
• This is a real attack caused by implementation errors

Standard Answer

Question (a): Eve Recovers Secret Key $x$

Eve's Observation:

• Transcript 1: $(t, c_1, z_1)$, where $z_1 = k + c_1 \cdot x \pmod{q}$
• Transcript 2: $(t, c_2, z_2)$, where $z_2 = k + c_2 \cdot x \pmod{q}$ (Note: $t$ is the same, meaning $k$ is the same)

Eve's Attack Method:

Step 1: Compute $z_1 - z_2$ $z_1 - z_2 = (k + c_1 \cdot x) - (k + c_2 \cdot x) = (c_1 - c_2) \cdot x \pmod{q}$

Step 2: Solve for $x$ Since $c_1 \neq c_2$ (two different challenges), $c_1 - c_2 \neq 0$, therefore we can compute:

$x = (z_1 - z_2) \cdot (c_1 - c_2)^{-1} \pmod{q}$

Verification: This is exactly the same formula as in Problem 1.2!

Key Observation:

• Eve only needs to observe two transcripts, without "rewinding" or "hacking"
• Since Peggy reuses $k$, the $t$ in both transcripts is the same
• Eve can extract $x$ using exactly the same algebraic method as in Problem 1.2

Practical Calculation Example: Assume $q = 23$, $c_1 = 5$, $c_2 = 7$, $z_1 = 12$, $z_2 = 18$.

$x = (12 - 18) \cdot (5 - 7)^{-1} \bmod 23 = (-6) \cdot (-2)^{-1} \bmod 23 = 6 \cdot 11 \bmod 23 = 66 \bmod 23 = 20$

where $(-2)^{-1} \bmod 23 = 11$ (because $-2 \equiv 21 \pmod{23}$, $21^{-1} \bmod 23 = 11$)

Question (b): Difference Between Two Scenarios

Scenario A: Extractor Forces $k$ Reuse (Soundness Proof)

Who Controls Reuse:

• Extractor controls: The extractor forces the prover to use the same commitment $t$ (thus the same $k$) through "rewinding" techniques
• This is a theoretical thought experiment used to prove Special Soundness

Why It's a Feature:

1. Theoretical Proof Tool: Rewinding is a tool for formal proofs, not a real attack
2. Proves Security: By proving "if a prover can pass the rewinding test, then the secret can be extracted", we prove the security of the protocol
3. Does Not Rely on Implementation Errors: This is part of the protocol design and does not rely on implementation errors

Scenario B: Prover Accidentally Reuses $k$ (Real-World Attack)

Who Controls Reuse:

• Prover controls: The prover accidentally reuses the same $k$ due to implementation errors (laziness, random number generator failure, etc.)
• This is an error in real-world implementation

Why It's a Fatal Bug:

1. Real Attack: An attacker can observe two transcripts and directly extract the secret
2. No Special Ability Needed: The attacker does not need "rewinding" ability, only needs to observe communication
3. Complete Security Breach: The secret key is completely leaked, and the security of the protocol is completely broken

Comparison Summary:

Feature	Scenario A (Extractor Forces Reuse)	Scenario B (Prover Accidentally Reuses)
Controller	Extractor (theoretical entity)	Prover (real implementation)
Purpose	Prove protocol security	Real attack
Nature	Theoretical tool (feature)	Implementation error (fatal bug)
Attacker Ability	Needs "rewinding" ability	Only needs to observe communication
Result	Proves Special Soundness	Complete security breach

Key Lessons:

• Nonce reuse is fatal: In real-world implementation, we must ensure that each proof uses a new random number $k$
• Importance of random number generator: Must use a cryptographically secure random number generator
• Importance of implementation security: Even if the protocol design is secure, implementation errors can lead to complete security breaches

---

Summary

Key Knowledge Points

1. Importance of Soundness: The protocol must ensure that provers without the secret cannot pass verification
2. Importance of Challenge Randomness: Soundness depends on the randomness and unpredictability of challenges
3. Special Soundness: Through rewinding techniques, we can prove knowledge soundness
4. Danger of Nonce Reuse: In real-world implementation, reusing random numbers leads to secret leakage

Practical Considerations

1. Use cryptographically secure random number generators: Ensure each proof uses a new random number
2. Verify challenge randomness: The verifier must use truly random challenges
3. Implementation security: Even if the protocol design is secure, implementation errors can lead to security breaches

Protocol Design Principles

1. Completeness: Honest provers should be able to pass verification
2. Soundness: Provers without the secret should be rejected
3. Zero-Knowledge: The verifier should not obtain information about the secret
4. Knowledge Extraction: Provers who can pass verification should have extractable knowledge (Special Soundness)

---

Problem 2: Secure Voting Protocol

Problem Background and Core Challenges

Problem 2 designs a secure electronic voting system based on the ElGamal encryption scheme. The protocol needs to satisfy:

1. Vote Confidentiality: No one can know the content of individual votes
2. Vote Validity: Each vote must be 0 or 1
3. Correct Vote Counting: Can correctly count the total votes
4. Verifiability: Use zero-knowledge proofs to ensure vote validity

Basic Structure of ElGamal Voting Protocol

Public Parameters:

• Group $G$: A cyclic group of prime order $q$ with generator $g$

Keys:

• Private Key (Tally Center): $x \in \mathbb{Z}_q$
• Public Key: $h = g^x$

Valid Vote: $v \in \{0, 1\}$

Vote Encryption:

• Voter selects random $r \in \mathbb{Z}_q$
• Computes ciphertext $C = (c_1, c_2)$, where:
  • $c_1 = g^r$
  • $c_2 = h^r \cdot g^v$

---

Problem 2.1: Homomorphic Aggregation

Problem Description

Scenario: There are $N$ voters who produce individual ciphertexts $C_1, C_2, \ldots, C_N$. Each ciphertext $C_i$ is defined as $(c_{1,i}, c_{2,i})$.

Task: Define an aggregated ciphertext $C_{agg}$ that represents the encryption of the sum of votes $V_{total} = \sum_{i=1}^N v_i$.

Requirement: Show the mathematical derivation.

In-Depth Analysis

Multiplicative Homomorphism of ElGamal

Homomorphic Property of ElGamal Encryption:

• Given two ciphertexts $C_1 = (c_{1,1}, c_{2,1})$ and $C_2 = (c_{1,2}, c_{2,2})$
• If $C_1$ encrypts $v_1$ and $C_2$ encrypts $v_2$
• Then $C_1 \cdot C_2 = (c_{1,1} \cdot c_{1,2}, c_{2,1} \cdot c_{2,2})$ encrypts $v_1 + v_2$ (in the exponent)

Key Observation:

• ElGamal's plaintext space is group $G$
• If $v \in \{0, 1\}$, then $g^v \in \{g^0, g^1\} = \{1, g\}$
• Ciphertext $C = (g^r, h^r \cdot g^v)$ actually encrypts $g^v$
• The product of multiple ciphertexts yields $g^{v_1 + v_2 + \ldots + v_N} = g^{V_{total}}$

Standard Answer

Mathematical Derivation

Encryption of Single Vote: For voter $i$, vote $v_i \in \{0, 1\}$, random number $r_i \in \mathbb{Z}_q$: $C_i = (c_{1,i}, c_{2,i}) = (g^{r_i}, h^{r_i} \cdot g^{v_i})$

Construction of Aggregated Ciphertext:

Perform component-wise multiplication on all $N$ ciphertexts:

$C_{agg} = \prod_{i=1}^N C_i = \left(\prod_{i=1}^N c_{1,i}, \prod_{i=1}^N c_{2,i}\right)$

Compute First Component: $c_{1,agg} = \prod_{i=1}^N c_{1,i} = \prod_{i=1}^N g^{r_i} = g^{\sum_{i=1}^N r_i} = g^{R_{total}}$

where $R_{total} = \sum_{i=1}^N r_i$.

Compute Second Component: $c_{2,agg} = \prod_{i=1}^N c_{2,i} = \prod_{i=1}^N (h^{r_i} \cdot g^{v_i}) = \prod_{i=1}^N h^{r_i} \cdot \prod_{i=1}^N g^{v_i} = h^{\sum_{i=1}^N r_i} \cdot g^{\sum_{i=1}^N v_i} = h^{R_{total}} \cdot g^{V_{total}}$

Aggregated Ciphertext: $C_{agg} = (c_{1,agg}, c_{2,agg}) = \left(g^{R_{total}}, h^{R_{total}} \cdot g^{V_{total}}\right)$

Verification: The aggregated ciphertext $C_{agg}$ has the same form as a single vote encryption:

• First component: $g^{R_{total}}$ (where $R_{total} = \sum_{i=1}^N r_i$ is the sum of random numbers)
• Second component: $h^{R_{total}} \cdot g^{V_{total}}$ (where $V_{total} = \sum_{i=1}^N v_i$ is the total votes)

Therefore, $C_{agg}$ indeed encrypts $g^{V_{total}}$, i.e., the encryption of the total votes.

---

Problem 2.2: Decryption

Problem Description

Describe the procedure the tally center uses to recover the integer value $V_{total}$ from $C_{agg}$ using the secret key $x$. Explain why this decryption method is computationally feasible in the context of an election.

In-Depth Analysis

ElGamal Decryption Process

Standard ElGamal Decryption:

• Given ciphertext $C = (c_1, c_2) = (g^r, h^r \cdot g^v)$
• Using private key $x$ (where $h = g^x$) to decrypt:
  • Compute shared secret: $s = c_1^x = (g^r)^x = g^{rx} = h^r$
  • Recover plaintext: $g^v = \frac{c_2}{s} = \frac{h^r \cdot g^v}{h^r} = g^v$

Recovering $v$ from $g^v$:

• If $v \in \{0, 1\}$, then $g^v \in \{g^0, g^1\} = \{1, g\}$
• Can recover $v$ by simple comparison:
  • If $g^v = 1$, then $v = 0$
  • If $g^v = g$, then $v = 1$

For Aggregated Ciphertext:

• After decryption, we get $g^{V_{total}}$
• Need to recover $V_{total}$ from $g^{V_{total}}$
• This requires computing discrete logarithm, but $V_{total}$ has a small range ($0 \leq V_{total} \leq N$)

Standard Answer

Decryption Process

Step 1: Compute Shared Secret $s = c_{1,agg}^x = (g^{R_{total}})^x = g^{x \cdot R_{total}} = h^{R_{total}}$

Step 2: Recover $g^{V_{total}}$ $g^{V_{total}} = \frac{c_{2,agg}}{s} = \frac{h^{R_{total}} \cdot g^{V_{total}}}{h^{R_{total}}} = g^{V_{total}}$

Step 3: Compute Discrete Logarithm to Recover $V_{total}$ $V_{total} = \log_g(g^{V_{total}})$

Computational Feasibility Analysis:

1. $V_{total}$ has a small range:

   • $V_{total} = \sum_{i=1}^N v_i$, where each $v_i \in \{0, 1\}$
   • Therefore $0 \leq V_{total} \leq N$
   • In elections, $N$ is usually a manageable number (e.g., thousands to millions)

2. Brute force search is feasible:

   • Since $V_{total}$ has a small range, we can use brute force search:
     • For $i = 0, 1, 2, \ldots, N$:
       • Compute $g^i$
       • If $g^i = g^{V_{total}}$, then $V_{total} = i$
   • Time complexity: $O(N)$, which is feasible for reasonable values of $N$ (e.g., $N \leq 10^6$)

3. No need for general discrete logarithm algorithms:

   • General discrete logarithm algorithms (such as number field sieve) are computationally hard for large prime-order groups
   • But since $V_{total}$ has a small range, we don't need to use these algorithms
   • Simple brute force search is sufficient

Summary: This decryption method is computationally feasible in the election context because the total vote count $V_{total}$ is bounded by the number of voters $N$, and can be recovered using simple brute force search in polynomial time.

---

Problem 2.3: Zero-Knowledge Proof (Sigma Protocol)

Problem Description

A malicious voter might attempt to encrypt a value other than 0 or 1 (e.g., $v = 5$) to manipulate the outcome. To prevent this, every voter must provide a zero-knowledge proof that their ciphertext $C = (c_1, c_2)$ encrypts either 0 or 1, without revealing which one.

Design a Sigma protocol (an interactive 3-move protocol) for this purpose.

Hint: Formulate this as an OR-proof showing that $(g, h, c_1, c_2)$ is a Diffie-Hellman tuple OR $(g, h, c_1, c_2 \cdot g^{-1})$ is a Diffie-Hellman tuple.

In-Depth Analysis

Diffie-Hellman Tuple

Definition of Diffie-Hellman Tuple:

• A quadruple $(g, h, A, B)$ is a Diffie-Hellman tuple if there exists $r$ such that $A = g^r$ and $B = h^r$
• Equivalently, $\log_g A = \log_h B$

In the Voting Protocol:

• Ciphertext $C = (c_1, c_2) = (g^r, h^r \cdot g^v)$
• If $v = 0$, then $c_2 = h^r \cdot g^0 = h^r$, so $(g, h, c_1, c_2) = (g, h, g^r, h^r)$ is a Diffie-Hellman tuple
• If $v = 1$, then $c_2 = h^r \cdot g^1 = h^r \cdot g$, so $c_2 \cdot g^{-1} = h^r$, thus $(g, h, c_1, c_2 \cdot g^{-1}) = (g, h, g^r, h^r)$ is a Diffie-Hellman tuple

OR Proof

Goal of OR Proof:

• The prover wants to prove: knows $r$ such that $(g, h, c_1, c_2)$ is a Diffie-Hellman tuple, OR knows $r$ such that $(g, h, c_1, c_2 \cdot g^{-1})$ is a Diffie-Hellman tuple
• But does not reveal which one

Standard Answer

Sigma Protocol Design

Protocol Setup:

• Public input: $(g, h, c_1, c_2)$
• Prover's secret: $r$ (such that $c_1 = g^r$)
• Prover's goal: Prove $v \in \{0, 1\}$, i.e.:
  • Case 1: $v = 0$, then $(g, h, c_1, c_2)$ is a Diffie-Hellman tuple
  • Case 2: $v = 1$, then $(g, h, c_1, c_2 \cdot g^{-1})$ is a Diffie-Hellman tuple

Protocol Steps:

Step 1: Commit

The prover needs to generate commitments for both cases:

For the true case (assuming $v = 0$, i.e., $(g, h, c_1, c_2)$ is a Diffie-Hellman tuple):

• The prover knows $r$ such that $c_1 = g^r$ and $c_2 = h^r$
• The prover selects random $k_0 \leftarrow \mathbb{Z}_q$
• Computes commitments: $a_0 = g^{k_0}$, $b_0 = h^{k_0}$
• Sends $(a_0, b_0)$ to the verifier

For the simulated case ($v = 1$ case):

• The prover does not know $r'$ such that $c_1 = g^{r'}$ and $c_2 \cdot g^{-1} = h^{r'}$
• The prover selects random $k_1 \leftarrow \mathbb{Z}_q$ and random challenge $c_1 \leftarrow \mathbb{Z}_q$
• Computes simulated response: $z_1 \leftarrow \mathbb{Z}_q$
• Computes simulated commitment: $a_1 = g^{z_1} \cdot c_1^{-c_1}$, $b_1 = h^{z_1} \cdot (c_2 \cdot g^{-1})^{-c_1}$
• Sends $(a_1, b_1)$ to the verifier

Step 2: Challenge

The verifier selects random challenge $c \leftarrow \mathbb{Z}_q$ and sends it to the prover.

Step 3: Response

The prover needs to distribute the challenge:

For the true case ($v = 0$):

• The prover sets $c_0 = c - c_1 \pmod{q}$
• Computes response: $z_0 = k_0 + c_0 \cdot r \pmod{q}$
• Sends $(c_0, z_0, c_1, z_1)$ to the verifier

For the simulated case ($v = 1$):

• If $v = 1$, then the prover knows $r$ such that $c_1 = g^r$ and $c_2 \cdot g^{-1} = h^r$
• Similarly, the prover will generate a real proof for the $v = 1$ case and a simulated proof for the $v = 0$ case

Step 4: Verify

The verifier checks:

1. Challenge distribution: $c_0 + c_1 \equiv c \pmod{q}$

2. For case 0 ($(g, h, c_1, c_2)$ is a Diffie-Hellman tuple):

   • $g^{z_0} = a_0 \cdot c_1^{c_0}$
   • $h^{z_0} = b_0 \cdot c_2^{c_0}$

3. For case 1 ($(g, h, c_1, c_2 \cdot g^{-1})$ is a Diffie-Hellman tuple):

   • $g^{z_1} = a_1 \cdot c_1^{c_1}$
   • $h^{z_1} = b_1 \cdot (c_2 \cdot g^{-1})^{c_1}$

If all checks pass, the verifier accepts the proof.

Protocol Summary:

Complete Protocol Flow:

1. P → V: $(a_0, b_0, a_1, b_1)$ (commitments for both cases)

2. V → P: $c$ (random challenge)

3. P → V: $(c_0, z_0, c_1, z_1)$ (challenge distribution and responses)

4. V verifies:

   • $c_0 + c_1 \equiv c \pmod{q}$
   • $g^{z_0} = a_0 \cdot c_1^{c_0}$ and $h^{z_0} = b_0 \cdot c_2^{c_0}$
   • $g^{z_1} = a_1 \cdot c_1^{c_1}$ and $h^{z_1} = b_1 \cdot (c_2 \cdot g^{-1})^{c_1}$

Security:

• Completeness: If $v \in \{0, 1\}$, an honest prover can always pass verification
• Soundness: If $v \notin \{0, 1\}$, the prover cannot pass verification (because neither case holds)
• Zero-Knowledge: The verifier cannot know whether $v$ is 0 or 1 (because both cases provide valid proofs)

---

Problem 2.4: Non-Interactive Proof

Problem Description

Apply the Fiat-Shamir heuristic to the protocol designed in Question 2.3 to make it non-interactive. Specify how the challenge is computed.

In-Depth Analysis

Fiat-Shamir Heuristic

Fiat-Shamir Heuristic:

• Converts interactive zero-knowledge proofs into non-interactive zero-knowledge proofs
• Core idea: Use a hash function instead of the verifier's random challenge
• Challenge is computed as: $c = H(\text{public input} || \text{commitment})$, where $H$ is a hash function (in the random oracle model)

Advantages:

• No interaction needed, the prover can generate the proof independently
• The proof can be publicly verified
• Suitable for blockchain and other scenarios

Security:

• Under the random oracle model, the security of non-interactive proofs is equivalent to interactive proofs

Standard Answer

Applying Fiat-Shamir Heuristic

Modified Non-Interactive Protocol:

Step 1: Commit (same as interactive protocol)

The prover generates commitments $(a_0, b_0, a_1, b_1)$.

Step 2: Compute Challenge (using Fiat-Shamir)

The prover computes the challenge: $c = H(g || h || c_1 || c_2 || a_0 || b_0 || a_1 || b_1)$

where $H$ is a cryptographic hash function (e.g., SHA-256), modeled in the random oracle model.

Step 3: Response (same as interactive protocol)

The prover computes responses $(c_0, z_0, c_1, z_1)$, where $c_0 + c_1 \equiv c \pmod{q}$.

Step 4: Verify (same as interactive protocol)

The verifier:

1. Recomputes the challenge: $c' = H(g || h || c_1 || c_2 || a_0 || b_0 || a_1 || b_1)$
2. Checks $c' = c$
3. Performs the same verification checks as the interactive protocol

Complete Non-Interactive Proof:

The prover outputs: $\pi = (a_0, b_0, a_1, b_1, c_0, z_0, c_1, z_1)$

The verifier verifies:

1. Computes $c = H(g || h || c_1 || c_2 || a_0 || b_0 || a_1 || b_1)$
2. Checks $c_0 + c_1 \equiv c \pmod{q}$
3. Checks $g^{z_0} = a_0 \cdot c_1^{c_0}$ and $h^{z_0} = b_0 \cdot c_2^{c_0}$
4. Checks $g^{z_1} = a_1 \cdot c_1^{c_1}$ and $h^{z_1} = b_1 \cdot (c_2 \cdot g^{-1})^{c_1}$

Key Points:

1. Challenge computation:

   • The challenge $c$ is the output of the hash function, depending on all public inputs and commitments
   • This ensures the prover cannot "choose" the challenge (because commitments are already fixed)

2. Random oracle model:

   • The hash function $H$ is modeled in the random oracle model
   • This ensures the randomness and unpredictability of the challenge

3. Non-interactivity:

   • The prover can independently generate a complete proof without interacting with the verifier
   • The proof can be publicly verified, anyone can verify the validity of the proof

Practical Applications:

• In electronic voting systems, voters can independently generate votes and proofs
• Proofs can be stored on the blockchain for anyone to verify
• No online verifier needed, improving system scalability

---

Summary

Key Knowledge Points

1. ElGamal Homomorphic Encryption: Supports multiplication operations on ciphertexts, enabling vote aggregation
2. Homomorphic Aggregation: Through component-wise multiplication of ciphertexts, we can compute the encryption of total votes
3. Small-Range Discrete Logarithm: When the value range is small, brute force search can be used
4. OR Proof: Used to prove that vote values are in the allowed range without revealing the specific value
5. Fiat-Shamir Heuristic: Converts interactive proofs into non-interactive proofs

Practical Considerations

1. Vote Validity Verification: Must use zero-knowledge proofs to ensure each vote is 0 or 1
2. Random Number Generation: Voters must use cryptographically secure random number generators
3. Key Management: The tally center's private key must be securely stored
4. Verifiability: Non-interactive proofs enable public verification of votes

---

Problem 3: BLS Digital Signature

Problem Background and Core Challenges

Problem 3 introduces the BLS (Boneh-Lynn-Shacham) digital signature scheme, a digital signature scheme based on bilinear pairings. BLS signatures have advantages such as short signatures and aggregability, and are widely used in blockchain and distributed systems.

Basic Concepts of Bilinear Pairing

Bilinear Pairing:

• Let $G_0$, $G_1$, and $G_T$ be three cyclic groups of prime order $q$
• Let $g_0$ be a generator of $G_0$ and $g_1$ be a generator of $G_1$
• A bilinear pairing is an efficiently computable function $e: G_0 \times G_1 \rightarrow G_T$

Properties of Bilinear Pairing:

1. Bilinearity: For all $u \in G_0$, $v \in G_1$, and $a, b \in \mathbb{Z}_q$: $e(u^a, v^b) = e(u, v)^{ab}$

2. Non-degeneracy: $e(g_0, g_1) \neq 1 \text{ in } G_T$

Computational co-Diffie-Hellman (co-CDH) Problem

co-CDH Problem:

• Given: Tuple $(g_0, g_0^{\alpha}, g_0^{\beta}) \in G_0$ and $(g_1, g_1^{\alpha}) \in G_1$, where $\alpha, \beta \in \mathbb{Z}_q$ are unknown random numbers
• Problem: Compute $g_0^{\alpha\beta} \in G_0$
• Assumption: For appropriate groups, the co-CDH problem is computationally intractable

BLS Signature Scheme

Setup:

• Groups $G_0$, $G_1$, $G_T$ and pairing $e$ are public parameters
• Let $H: \{0,1\}^* \rightarrow G_0$ be a cryptographic hash function (modeled in the random oracle model)

KeyGen:

• Select random secret $\alpha \in \mathbb{Z}_q$
• Private Key (Signing Key): $sk = \alpha$
• Public Key (Verification Key): $pk = g_1^{\alpha} \in G_1$

Sign(sk, m):

• To sign message $m$, compute $h = H(m) \in G_0$
• Output signature: $\sigma = h^{\alpha} \in G_0$

**Verify(pk, m, \sigma)$:

• Compute $h = H(m)$
• Accept if and only if: $e(\sigma, g_1) = e(h, pk)$

---

Problem 3.1: Correctness

Problem Description

Prove that a validly generated BLS signature will always pass the verification equation. Use the bilinearity property of pairing $e$.

In-Depth Analysis

Key to Correctness Proof

What needs to be proved:

• If signature $\sigma = h^{\alpha}$ is correctly generated using private key $\alpha$ for message $m$
• Then the verification equation $e(\sigma, g_1) = e(h, pk)$ should hold

Using Bilinearity Property:

• The bilinearity property allows us to "move" exponents inside the pairing
• This is the key to the proof

Standard Answer

Correctness Proof

Given:

• Private key: $sk = \alpha$
• Public key: $pk = g_1^{\alpha}$
• Message: $m$
• Signature: $\sigma = h^{\alpha}$, where $h = H(m) \in G_0$

Verification Equation: $e(\sigma, g_1) = e(h, pk)$

Proof Process:

Left Side: $e(\sigma, g_1) = e(h^{\alpha}, g_1)$

Using Bilinearity Property: According to the bilinearity property $e(u^a, v^b) = e(u, v)^{ab}$, we have: $e(h^{\alpha}, g_1) = e(h, g_1)^{\alpha}$

Right Side: $e(h, pk) = e(h, g_1^{\alpha})$

Using Bilinearity Property Again: $e(h, g_1^{\alpha}) = e(h, g_1)^{\alpha}$

Therefore: $e(\sigma, g_1) = e(h^{\alpha}, g_1) = e(h, g_1)^{\alpha} = e(h, g_1^{\alpha}) = e(h, pk) \quad \checkmark$

Conclusion: A validly generated BLS signature will always pass the verification equation. ✓

---

Problem 3.2: Security Reduction

Problem Description

We want to prove that if the co-CDH assumption holds, then BLS is secure against Existential Forgery under Chosen Message Attacks (EUF-CMA) in the Random Oracle Model.

Let $A$ be an adversary that makes at most $q_H$ queries to the hash oracle $H$ and $q_S$ queries to the signing oracle, and produces a valid forgery with non-negligible probability.

Construct a simulator $B$ that uses $A$ to solve the co-CDH problem.

Hint: $B$ receives a co-CDH challenge $(u_0, u_0^{\alpha}, u_0^{\beta}) \in G_0$ and $(g_1, g_1^{\alpha}) \in G_1$. $B$ should set the public key $pk = g_1^{\alpha}$.

Question (a): How should $B$ program the Random Oracle $H(m)$ so that it can answer signing queries for some messages (where it knows the discrete log of $H(m)$) but embed the challenge term $u_0^{\beta}$ into the hash of the target message $m^*$?

Question (b): How does $B$ extract the solution $u_0^{\alpha\beta}$ from $A$'s forgery?

In-Depth Analysis

EUF-CMA Security

Existential Forgery:

• The adversary can forge a signature for some message (does not need to be a specific message)
• But the adversary cannot choose which message to forge (during the query phase)

Chosen Message Attack:

• The adversary can query the signing oracle to obtain signatures for arbitrary messages
• This simulates real-world scenarios where the adversary can observe legitimate signatures

Security Reduction Approach

Reduction Goal:

• Assume there exists an adversary $A$ that can forge BLS signatures with non-negligible probability
• Construct algorithm $B$ that uses $A$ to solve the co-CDH problem
• If $A$ succeeds, then $B$ can solve the co-CDH problem
• This contradicts the hardness of the co-CDH problem
• Therefore, BLS is EUF-CMA secure

Key Challenges:

1. Simulate Signing Oracle: $B$ needs to be able to answer $A$'s signing queries, but $B$ does not know the private key $\alpha$
2. Embed Challenge: $B$ needs to embed the co-CDH challenge into the hash of some message
3. Extract Solution: Extract the solution to the co-CDH problem from $A$'s forgery

Standard Answer

Question (a): Programming the Random Oracle

$B$'s Strategy:

Step 1: Initialization

• $B$ receives co-CDH challenge: $(u_0, u_0^{\alpha}, u_0^{\beta}) \in G_0$ and $(g_1, g_1^{\alpha}) \in G_1$
• $B$ sets public key: $pk = g_1^{\alpha}$ (this is part of the challenge)
• $B$ maintains a hash table $T$ to store values of $H(m)$

Step 2: Programming Random Oracle $H(m)$

For each hash query $m_i$ ($i = 1, 2, \ldots, q_H$):

1. If $m_i$ is a message for signing query ($B$ needs to be able to generate signatures):

   • $B$ randomly selects $s_i \leftarrow \mathbb{Z}_q$
   • $B$ sets: $H(m_i) = u_0^{s_i}$ (where $u_0$ is the generator of $G_0$, from the challenge)
   • $B$ stores $(m_i, s_i, H(m_i))$ in table $T$
   • When $A$ queries signature for $m_i$, $B$ computes: $\sigma_i = (u_0^{\alpha})^{s_i} = u_0^{\alpha s_i}$
   • Key: $B$ has $u_0^{\alpha}$ (from the challenge), so can compute $\sigma_i = (u_0^{\alpha})^{s_i}$

2. If $m_i$ is the target message $m^*$ ($B$ hopes $A$ will forge this message):

   • $B$ sets: $H(m^*) = u_0^{\beta} \in G_0$
   • $B$ stores $(m^*, \bot, u_0^{\beta})$ in table $T$ ($\bot$ indicates unknown discrete logarithm)
   • Key Observation: $B$ does not know the discrete logarithm of $H(m^*)$, but this is part of the challenge

Verification of Signature Validity: $e(\sigma_i, g_1) = e(u_0^{\alpha s_i}, g_1) = e(u_0, g_1)^{\alpha s_i}$ $e(H(m_i), pk) = e(u_0^{s_i}, g_1^{\alpha}) = e(u_0, g_1)^{s_i \alpha} = e(u_0, g_1)^{\alpha s_i}$

Therefore, $e(\sigma_i, g_1) = e(H(m_i), pk)$, signature is valid! ✓

For Target Message $m^*$:

• $B$ sets: $H(m^*) = u_0^{\beta}$ (this is part of the challenge)
• $B$ does not know the discrete logarithm of $H(m^*)$, so cannot generate a signature for $m^*$
• This forces $A$ to forge the signature for $m^*$

Question (b): Extracting Solution from Forgery

$A$'s Forgery:

• $A$ outputs forgery $(m^*, \sigma^*)$, where $m^*$ is a message that $A$ has not queried for signature
• Forgery satisfies: $e(\sigma^*, g_1) = e(H(m^*), pk) = e(u_0^{\beta}, g_1^{\alpha})$

$B$ Extracts Solution:

Step 1: Verify Forgery Validity $e(\sigma^*, g_1) = e(u_0^{\beta}, g_1^{\alpha})$

Step 2: Use Bilinearity Property $e(\sigma^*, g_1) = e(u_0^{\beta}, g_1^{\alpha}) = e(u_0, g_1)^{\beta \alpha}$

Step 3: Extract $u_0^{\alpha\beta}$

Since $e(\sigma^*, g_1) = e(u_0^{\beta}, g_1^{\alpha})$, and the pairing is non-degenerate, we have: $\sigma^* = u_0^{\alpha\beta}$

Verification: $e(\sigma^*, g_1) = e(u_0^{\alpha\beta}, g_1) = e(u_0, g_1)^{\alpha\beta}$ $e(u_0^{\beta}, g_1^{\alpha}) = e(u_0, g_1)^{\beta\alpha} = e(u_0, g_1)^{\alpha\beta}$

Therefore, $\sigma^* = u_0^{\alpha\beta}$ is the solution to the co-CDH problem.

$B$'s Output:

• $B$ outputs $\sigma^*$ as the solution $u_0^{\alpha\beta}$ to the co-CDH problem

Success Probability:

• If $A$ succeeds with probability $\epsilon$, and $m^*$ is the target message chosen by $A$ (probability at least $1/q_H$), then $B$ solves the co-CDH problem with probability at least $\epsilon/q_H$
• If $\epsilon$ is non-negligible, then $\epsilon/q_H$ is also non-negligible (since $q_H$ is polynomial)

Conclusion:

• If there exists an adversary $A$ that can forge BLS signatures with non-negligible probability, then there exists an algorithm $B$ that can solve the co-CDH problem with non-negligible probability
• This contradicts the hardness of the co-CDH problem
• Therefore, BLS is EUF-CMA secure under the co-CDH assumption and the random oracle model

---

Problem 3.3: Signature Aggregation

Problem Description

One of the most powerful features of BLS is non-interactive aggregation. Suppose we have $n$ users with public keys $pk_1, \ldots, pk_n$. Each user $i$ signs a distinct message $m_i$ to produce signature $\sigma_i$.

The aggregate signature is computed as $\sigma_{agg} = \prod_{i=1}^n \sigma_i$ (computed in group $G_0$).

Write down the verification equation for the aggregate signature $\sigma_{agg}$ given the set of public keys $\{pk_1, \ldots, pk_n\}$ and messages $\{m_1, \ldots, m_n\}$. Prove that the verification equation holds if all individual signatures are valid.

In-Depth Analysis

Advantages of Signature Aggregation

Non-Interactive Aggregation:

• Multiple signatures can be aggregated into one signature without interaction between signers
• The aggregate signature has the same size as a single signature
• Can efficiently batch verify multiple signatures

Application Scenarios:

• Multi-signatures in blockchain
• Batch verification in distributed systems
• Reduce storage and transmission overhead

Standard Answer

Verification Equation for Aggregate Signature

Given:

• $n$ users' public keys: $pk_1, \ldots, pk_n$, where $pk_i = g_1^{\alpha_i}$ (user $i$'s private key is $\alpha_i$)
• $n$ messages: $m_1, \ldots, m_n$
• Aggregate signature: $\sigma_{agg} = \prod_{i=1}^n \sigma_i$, where $\sigma_i = H(m_i)^{\alpha_i}$

Verification Equation: $e(\sigma_{agg}, g_1) = \prod_{i=1}^n e(H(m_i), pk_i)$

Equivalent Form (using bilinearity property of pairing): $e(\sigma_{agg}, g_1) = \prod_{i=1}^n e(H(m_i), g_1^{\alpha_i})$

Correctness Proof

Assumption: All individual signatures $\sigma_i$ are valid, i.e., for each $i$: $e(\sigma_i, g_1) = e(H(m_i), pk_i)$

Proving the Verification Equation for Aggregate Signature:

Left Side: $e(\sigma_{agg}, g_1) = e\left(\prod_{i=1}^n \sigma_i, g_1\right)$

Using Bilinearity Property: Since the pairing is bilinear, for the product of group elements, we have: $e\left(\prod_{i=1}^n \sigma_i, g_1\right) = \prod_{i=1}^n e(\sigma_i, g_1)$

Using Validity of Individual Signatures: $\prod_{i=1}^n e(\sigma_i, g_1) = \prod_{i=1}^n e(H(m_i), pk_i)$

Right Side: $\prod_{i=1}^n e(H(m_i), pk_i)$

Therefore: $e(\sigma_{agg}, g_1) = \prod_{i=1}^n e(\sigma_i, g_1) = \prod_{i=1}^n e(H(m_i), pk_i) \quad \checkmark$

Conclusion: If all individual signatures are valid, then the verification equation for the aggregate signature holds. ✓

Detailed Derivation (using bilinearity property):

For each $i$, since $\sigma_i = H(m_i)^{\alpha_i}$ and $pk_i = g_1^{\alpha_i}$: $e(\sigma_i, g_1) = e(H(m_i)^{\alpha_i}, g_1) = e(H(m_i), g_1)^{\alpha_i} = e(H(m_i), g_1^{\alpha_i}) = e(H(m_i), pk_i)$

Therefore: $e(\sigma_{agg}, g_1) = e\left(\prod_{i=1}^n H(m_i)^{\alpha_i}, g_1\right) = \prod_{i=1}^n e(H(m_i)^{\alpha_i}, g_1) = \prod_{i=1}^n e(H(m_i), pk_i)$

---

Problem 3.4: Rogue Public Key Attack

Problem Description

Consider the special case where multiple users sign the same message $m$. The verification equation simplifies significantly.

Question 1: Write down the simplified verification equation for an aggregate signature $\sigma_{agg}$ on a single message $m$ verified against public keys $pk_1, \ldots, pk_n$.

Question 2: Suppose Alice has a public key $pk_A$. An adversary wants to forge an aggregate signature that appears to come from both Alice and the Adversary on a message $m$. The adversary can choose his own public key $pk_{adv}$ arbitrarily.

Show how the adversary can choose a specific $pk_{adv}$ (as a function of $pk_A$) and generate a valid aggregate signature $\sigma_{agg}$ for the set of keys $\{pk_A, pk_{adv}\}$ on message $m$, without knowing Alice's secret key.

Question 3: Briefly propose a simple countermeasure to prevent this attack.

In-Depth Analysis

Same Message Case

When All Messages Are the Same:

• $m_1 = m_2 = \ldots = m_n = m$
• $H(m_1) = H(m_2) = \ldots = H(m_n) = H(m) = h$
• The verification equation can be simplified

Rogue Public Key Attack

Attack Scenario:

• The adversary can freely choose their own public key
• The adversary wants to forge an aggregate signature that appears to come from Alice and the adversary
• The adversary does not know Alice's private key

Attack Method:

• The adversary can choose $pk_{adv}$ to make the verification equation easier to satisfy
• By carefully choosing $pk_{adv}$, the adversary can "cancel out" the part that requires Alice's signature

Standard Answer

Question 1: Simplified Verification Equation

When All Messages Are the Same ($m_1 = m_2 = \ldots = m_n = m$):

Let $h = H(m) \in G_0$.

Aggregate Signature: $\sigma_{agg} = \prod_{i=1}^n \sigma_i = \prod_{i=1}^n h^{\alpha_i} = h^{\sum_{i=1}^n \alpha_i}$

Simplified Verification Equation: $e(\sigma_{agg}, g_1) = e(h, \prod_{i=1}^n pk_i)$

Proof:

Left Side: $e(\sigma_{agg}, g_1) = e\left(h^{\sum_{i=1}^n \alpha_i}, g_1\right) = e(h, g_1)^{\sum_{i=1}^n \alpha_i}$

Right Side: $e(h, \prod_{i=1}^n pk_i) = e(h, \prod_{i=1}^n g_1^{\alpha_i}) = e(h, g_1^{\sum_{i=1}^n \alpha_i}) = e(h, g_1)^{\sum_{i=1}^n \alpha_i}$

Therefore, the verification equation holds. ✓

Simplified Form: $e(\sigma_{agg}, g_1) = e(h, pk_1 \cdot pk_2 \cdot \ldots \cdot pk_n)$

Question 2: Rogue Public Key Attack

Adversary's Goal:

• Forge aggregate signature $\sigma_{agg}$ that appears to come from Alice (public key $pk_A$) and the adversary (public key $pk_{adv}$)
• For message $m$
• The adversary does not know Alice's private key $\alpha_A$ (where $pk_A = g_1^{\alpha_A}$)

Adversary's Strategy:

Step 1: Choose Rogue Public Key

The adversary computes: $pk_{adv} = pk_A^{-1} = (g_1^{\alpha_A})^{-1} = g_1^{-\alpha_A}$

Step 2: Generate Aggregate Signature

The adversary computes: $\sigma_{agg} = h^0 = 1 \in G_0$

(where $h = H(m)$)

Step 3: Verify Attack Success

Verification equation: $e(\sigma_{agg}, g_1) = e(1, g_1) = 1$

$e(h, pk_A \cdot pk_{adv}) = e(h, pk_A \cdot pk_A^{-1}) = e(h, 1) = 1$

Therefore, $e(\sigma_{agg}, g_1) = e(h, pk_A \cdot pk_{adv}) = 1$, verification passes! ✓

Attack Success:

• The adversary successfully forged the aggregate signature
• The verifier will think this signature comes from Alice and the adversary
• But the adversary actually does not have Alice's signature, nor their own valid signature (because $pk_{adv} = pk_A^{-1}$ corresponds to private key $-\alpha_A$, which the adversary does not know)

Key Observation:

• By choosing $pk_{adv} = pk_A^{-1}$, the adversary makes $pk_A \cdot pk_{adv} = 1$
• Therefore, the verification equation becomes $e(\sigma_{agg}, g_1) = e(h, 1) = 1$
• The adversary can simply set $\sigma_{agg} = 1$ to satisfy the verification equation

Question 3: Countermeasure

Simple Countermeasure: Proof of Knowledge

Method: Require each user to provide a zero-knowledge proof when registering their public key, proving they know the discrete logarithm of the corresponding private key.

Specific Implementation:

1. Key Registration Phase:

   • User $i$ generates key pair: $(\alpha_i, pk_i = g_1^{\alpha_i})$
   • User $i$ generates zero-knowledge proof $\pi_i$ proving knowledge of $\alpha_i$ such that $pk_i = g_1^{\alpha_i}$
   • User $i$ submits $(pk_i, \pi_i)$ for registration

2. Verify Registration:

   • The verifier verifies the validity of $\pi_i$
   • Only public keys that pass verification are accepted

3. Prevent Attack:

   • The adversary cannot generate a valid proof of knowledge for $pk_{adv} = pk_A^{-1}$
   • Because the adversary does not know $-\alpha_A$ (the adversary does not know $\alpha_A$)
   • Therefore, $pk_{adv} = pk_A^{-1}$ cannot pass registration

Other Countermeasures:

1. Message Binding: Require each signer to include their own public key when signing, i.e., sign $H(m || pk_i)$ instead of $H(m)$

2. Public Key Aggregation: Use more complex aggregation schemes that require all public keys to be known before aggregation

3. Signer List: Maintain a trusted list of public keys, only accept signatures from public keys in the list

Simplest Countermeasure:

• Require Proof of Knowledge: Each public key must be accompanied by a zero-knowledge proof proving the registrant knows the corresponding private key
• This prevents adversaries from registering maliciously constructed public keys (such as $pk_A^{-1}$)

---

Summary

Key Knowledge Points

1. Bilinear Pairing: The foundation of BLS signatures, enabling efficient signature verification and aggregation
2. co-CDH Problem: The fundamental assumption for BLS security
3. Signature Aggregation: A powerful feature of BLS, allowing multiple signatures to be aggregated into one
4. Rogue Public Key Attack: When messages are the same, adversaries can forge aggregate signatures by choosing rogue public keys
5. Countermeasure: Use proof of knowledge to prevent rogue public key registration

Practical Considerations

1. Public Key Registration: Must require proof of knowledge to prevent rogue public key attacks
2. Message Uniqueness: If possible, avoid multiple users signing the same message
3. Key Management: Private keys must be securely stored
4. Batch Verification: Aggregate signatures can efficiently batch verify multiple signatures

Cryptography Final Exam Solutions

Problem 1: Concept Explanation

1.1 Hash Function

Knowledge Point Analysis

Basic Concept of Hash Functions:

• A hash function $H: \{0,1\}^* \rightarrow \{0,1\}^n$ maps inputs of arbitrary length to fixed-length outputs
• It is a fundamental tool in cryptography, used for data integrity verification, digital signatures, password storage, etc.

Three Basic Security Properties:

1. Preimage Resistance / One-Wayness: Given a hash value $y$, finding $x$ such that $H(x) = y$ is computationally infeasible
2. Second Preimage Resistance: Given $x$, finding $x' \neq x$ such that $H(x) = H(x')$ is computationally infeasible
3. Collision Resistance: Finding any $x \neq x'$ such that $H(x) = H(x')$ is computationally infeasible

Relationships Between Properties:

• Collision Resistance $\Rightarrow$ Second Preimage Resistance $\Rightarrow$ Preimage Resistance
• If a hash function is collision-resistant, then it is also second preimage-resistant and preimage-resistant

Standard Answer Format

Form: A hash function is a deterministic function $H: \{0,1\}^* \rightarrow \{0,1\}^n$ that maps binary strings of arbitrary length to fixed-length binary strings of length $n$.

Background: Hash functions are fundamental tools in cryptography, widely used in:

• Data integrity verification (e.g., file checksums)
• Digital signatures (e.g., RSA-FDH, BLS signatures)
• Password storage (e.g., bcrypt, scrypt)
• Blockchain (e.g., Bitcoin's Merkle tree)

Scenario: In practical applications, hash functions are used for:

1. File Integrity: Computing hash values of files to detect tampering
2. Password Storage: Storing hash values of passwords instead of plaintext passwords
3. Digital Signatures: Mapping messages to fixed length before signing
4. Commitment Schemes: Using hash functions to implement commitments

Benefit:

1. High Efficiency: Fast computation, suitable for processing large amounts of data
2. Fixed Output Length: Regardless of input length, output is always fixed length
3. One-Way Property: Difficult to recover original input from hash value
4. Avalanche Effect: Small changes in input cause large changes in output

---

1.2 1-n OT (1-out-of-n Oblivious Transfer)

Knowledge Point Analysis

Basic Concept of 1-n OT:

• 1-out-of-n OT is a generalization of 1-out-of-2 OT
• The sender has $n$ messages $m_1, m_2, \ldots, m_n$
• The receiver selects an index $i \in \{1, 2, \ldots, n\}$
• After the protocol, the receiver obtains $m_i$ but does not know other messages, and the sender does not know $i$

Security Requirements:

1. Receiver's Privacy: The sender cannot know which message the receiver selected
2. Sender's Privacy: The receiver cannot obtain unselected messages

Standard Answer Format

Form: 1-out-of-n Oblivious Transfer (1-n OT) is a cryptographic protocol that allows a receiver to select and obtain one message from the sender's $n$ messages, while the sender does not know which message the receiver selected.

Background: 1-n OT is a generalization of 1-out-of-2 OT, applied in the following scenarios:

• Privacy-preserving data queries
• Secure multi-party computation
• Electronic voting systems
• Privacy-preserving machine learning

Scenario: Typical application scenarios:

1. Privacy Query: A user wants to query a record from a database without letting the database know which record is queried
2. Privacy Auction: A bidder wants to obtain information about an item without revealing their interest
3. Privacy Data Sharing: One party wants to obtain data from another party without revealing their choice

Benefit:

1. Privacy Protection: Protects the receiver's choice privacy and the sender's message privacy
2. Flexibility: Supports selection from multiple options
3. Security: Based on cryptographic assumptions, provides formal security guarantees

---

1.3 IBE (Identity-Based Encryption)

Knowledge Point Analysis

Basic Concept of IBE:

• IBE is a public-key encryption scheme where the public key can be any string (e.g., email address, ID number)
• The private key is generated by a Key Generation Center (PKG) based on identity and master key
• No public key certificates are needed, simplifying key management

Components of IBE:

1. Setup: Generate system parameters and master key
2. Extract: Generate private key based on identity
3. Encrypt: Encrypt messages using identity
4. Decrypt: Decrypt messages using private key

Security:

• IBE security is based on bilinear pairings and hard problems (e.g., BDH problem)
• Need to address the key escrow problem (PKG knows all private keys)

Standard Answer Format

Form: Identity-Based Encryption (IBE) is a public-key encryption scheme where the public key can be any string (identity), and the private key is generated by a Key Generation Center based on identity and master key.

Background: IBE was proposed by Boneh and Franklin in 2001, solving the complexity of public key certificate management in traditional public-key encryption:

• Traditional schemes require Public Key Infrastructure (PKI) and certificates
• IBE uses identity (e.g., email address) as public key, no certificates needed

Scenario: Typical application scenarios:

1. Email Encryption: Using recipient's email address as public key to encrypt emails
2. Internet of Things: Using device ID as public key, simplifying key management
3. Cloud Storage: Using user identity to encrypt data stored in the cloud

Benefit:

1. Simplified Key Management: No public key certificates needed, identity is the public key
2. Flexibility: Can use any string as public key
3. Scalability: Suitable for large-scale deployment
4. Forward Security: Can revoke identity, making old ciphertexts undecryptable

---

1.4 MPC (Multi-Party Computation)

Knowledge Point Analysis

Basic Concept of MPC:

• MPC allows multiple parties to jointly compute a function without revealing their private inputs
• The computation result is correct, but no party can obtain other parties' private inputs

Security Models of MPC:

1. Semi-Honest Model: Parties follow the protocol but try to infer other parties' inputs from protocol execution
2. Malicious Model: Parties may not follow the protocol and try to break security

Implementation Methods of MPC:

• Secret Sharing
• Homomorphic Encryption
• Garbled Circuits
• Oblivious Transfer

Standard Answer Format

Form: Secure Multi-Party Computation (MPC) is a cryptographic protocol that allows multiple parties to jointly compute a function without revealing their private inputs, and obtain correct computation results.

Background: MPC was proposed by Yao in 1982, solving the following problems:

• Multiple parties need to jointly compute but do not want to reveal their private data
• Application scenarios include privacy-preserving data analysis, federated machine learning, privacy auctions, etc.

Scenario: Typical application scenarios:

1. Privacy-Preserving Data Analysis: Multiple hospitals want to jointly analyze medical data without revealing their patient data
2. Federated Machine Learning: Multiple companies want to jointly train models without revealing their training data
3. Privacy Auction: Multiple bidders want to determine the winner without revealing their bid prices
4. Electronic Voting: Multiple voters want to count voting results without revealing their voting content

Benefit:

1. Privacy Protection: Protects each party's private inputs
2. Correctness: Guarantees correctness of computation results
3. Flexibility: Can compute any function
4. Practicality: With the development of cryptography, MPC can now be applied in practical scenarios

---

Problem 2: Scheme Design

Problem Description

Design a secure file transfer scheme that satisfies the following requirements:

1. 10GB File [Large]: Need to handle large files
2. Payment (No one knows): Payment information is confidential, no one knows the payment amount
3. Integrity: File integrity
4. Only Bob can check the content: Only Bob can check the file content

Requirements: Select tools, explain the process, explain how each requirement is satisfied.

Knowledge Point Analysis

Core Challenges

1. Large File Processing:

   • 10GB file is too large to encrypt and transfer directly
   • Need to use stream encryption or block encryption
   • Consider efficiency issues

2. Payment Confidentiality:

   • Payment amount must be confidential
   • Can use homomorphic encryption or commitment schemes
   • Need to support payment verification without revealing amount

3. Integrity:

   • Need to detect if file has been tampered with
   • Can use hash functions or MAC
   • Need to support integrity verification for large files

4. Access Control:

   • Only Bob can decrypt and check file content
   • Need to use encryption schemes
   • Consider key distribution issues

Tool Selection

1. Symmetric Encryption: For encrypting large files (e.g., AES-256-CTR)
2. Public-Key Encryption: For encrypting symmetric keys (e.g., RSA-OAEP or ElGamal)
3. Hash Function: For integrity verification (e.g., SHA-256)
4. MAC: For authentication (e.g., HMAC-SHA256)
5. Commitment Scheme: For payment confidentiality (e.g., Pedersen commitment)

Standard Answer

Tool Selection

1. File Encryption:

• Symmetric Encryption: AES-256-CTR (stream encryption, suitable for large files)
• Key Encryption: RSA-OAEP or ElGamal (for encrypting symmetric keys)

2. Integrity Verification:

• Hash Function: SHA-256 (for computing file hash value)
• MAC: HMAC-SHA256 (for authentication)

3. Payment Confidentiality:

• Commitment Scheme: Pedersen commitment (for hiding payment amount)

Scheme Design

Phase 1: Initialization

1. Bob Generates Key Pair:

   • Bob generates RSA key pair: $(pk_B, sk_B)$
   • Bob sends public key $pk_B$ to Alice

2. Alice Generates File Key:

   • Alice randomly generates file encryption key: $K \leftarrow \{0,1\}^{256}$
   • Alice encrypts file using $K$: $C = \text{AES-CTR-Enc}(K, \text{File})$

Phase 2: Payment Processing

1. Alice Generates Payment Commitment:

   • Alice selects payment amount $p$ and random number $r$
   • Alice computes payment commitment: $C_p = g^p \cdot h^r$ (Pedersen commitment)
   • Alice sends $C_p$ to Bob (Bob does not know $p$)

2. Payment Verification (optional):

   • If payment verification is needed, Alice can open the commitment, but only under specific conditions
   • Or use zero-knowledge proof to prove payment amount is within reasonable range

Phase 3: File Transfer

1. Alice Encrypts File Key:

   • Alice encrypts file key using Bob's public key: $E_K = \text{RSA-Enc}(pk_B, K)$

2. Alice Computes File Hash:

   • Alice computes file hash value: $h = \text{SHA-256}(\text{File})$

3. Alice Generates MAC:

   • Alice uses shared key $K_{MAC}$ (or derived from $K$) to compute MAC:
   • $M = \text{HMAC-SHA256}(K_{MAC}, C || h || C_p)$

4. Alice Sends to Bob:

   • Alice sends: $(C, E_K, h, C_p, M)$ to Bob

Phase 4: Bob Receives and Verifies

1. Bob Decrypts File Key:

   • Bob uses private key to decrypt: $K = \text{RSA-Dec}(sk_B, E_K)$

2. Bob Decrypts File:

   • Bob uses $K$ to decrypt file: $\text{File} = \text{AES-CTR-Dec}(K, C)$

3. Bob Verifies Integrity:

   • Bob computes file hash: $h' = \text{SHA-256}(\text{File})$
   • Bob checks $h' = h$, if equal, file is intact

4. Bob Verifies MAC:

   • Bob computes MAC: $M' = \text{HMAC-SHA256}(K_{MAC}, C || h || C_p)$
   • Bob checks $M' = M$, if equal, data has not been tampered with

How Each Requirement is Satisfied

1. 10GB File [Large]:

• ✅ Use AES-CTR Stream Encryption: Can encrypt block by block, no need to load entire file into memory
• ✅ Block Transfer: Can divide file into multiple blocks, encrypt and transfer separately
• ✅ High Efficiency: Symmetric encryption is fast, suitable for large files

2. Payment (No one knows):

• ✅ Use Pedersen Commitment: $C_p = g^p \cdot h^r$ hides payment amount $p$
• ✅ Random Number $r$: Ensures commitments of the same amount look different
• ✅ Only Alice knows $p$ and $r$: Bob and others cannot infer $p$ from $C_p$

3. Integrity:

• ✅ SHA-256 Hash: Computes file hash value to detect any tampering
• ✅ HMAC: Provides authentication, prevents data modification
• ✅ Verification Mechanism: Bob can verify if file is intact

4. Only Bob can check the content:

• ✅ RSA Encrypt File Key: Only Bob's private key can decrypt $E_K$ to obtain $K$
• ✅ AES Encrypt File: Only Bob who has $K$ can decrypt the file
• ✅ Access Control: Others cannot obtain file content

---

Problem 3: ElGamal Voting System

3.1 Computation Flow: Given x, Compute y, C1, C2, r

Problem Construction

Problem: In the ElGamal encryption scheme, given:

• Group parameters: $p = 23$, $g = 5$ ($g$ is a generator of $\mathbb{Z}_{23}^*$)
• Private key: $x = 7$
• Message: $m = 12$
• Random number: $r = 3$

Please compute:

1. Public key $y$
2. Ciphertext $(C_1, C_2)$

Knowledge Point Analysis

ElGamal Encryption Scheme:

• Key Generation: Private key $x \in \mathbb{Z}_p^*$, public key $y = g^x \bmod p$
• Encryption: Select random $r \in \mathbb{Z}_p^*$, compute $C_1 = g^r \bmod p$, $C_2 = m \cdot y^r \bmod p$
• Decryption: Compute $m = C_2 \cdot (C_1^x)^{-1} \bmod p = C_2 \cdot C_1^{-x} \bmod p$

Standard Answer

Step 1: Compute Public Key $y$

$y = g^x \bmod p = 5^7 \bmod 23$

Compute $5^7 \bmod 23$:

• $5^1 = 5 \bmod 23 = 5$
• $5^2 = 25 \bmod 23 = 2$
• $5^4 = (5^2)^2 = 2^2 = 4 \bmod 23 = 4$
• $5^7 = 5^4 \cdot 5^2 \cdot 5^1 = 4 \cdot 2 \cdot 5 = 40 \bmod 23 = 17$

Therefore, $y = 17$.

Step 2: Compute Ciphertext $C_1$

$C_1 = g^r \bmod p = 5^3 \bmod 23 = 125 \bmod 23 = 10$

Step 3: Compute Ciphertext $C_2$

First compute $y^r \bmod p$: $y^r = 17^3 \bmod 23$

Compute $17^3 \bmod 23$:

• $17^1 = 17 \bmod 23 = 17$
• $17^2 = 289 \bmod 23 = 289 - 12 \times 23 = 289 - 276 = 13$
• $17^3 = 17^2 \cdot 17 = 13 \cdot 17 = 221 \bmod 23 = 221 - 9 \times 23 = 221 - 207 = 14$

Therefore, $y^r = 14$.

Then compute $C_2$: $C_2 = m \cdot y^r \bmod p = 12 \cdot 14 \bmod 23 = 168 \bmod 23 = 168 - 7 \times 23 = 168 - 161 = 7$

Result Summary:

• Public key: $y = 17$
• Ciphertext: $(C_1, C_2) = (10, 7)$
• Random number: $r = 3$

Verification (decryption): $m' = C_2 \cdot (C_1^x)^{-1} \bmod p = 7 \cdot (10^7)^{-1} \bmod 23$

Compute $10^7 \bmod 23$:

• $10^1 = 10 \bmod 23 = 10$
• $10^2 = 100 \bmod 23 = 8$
• $10^4 = (10^2)^2 = 8^2 = 64 \bmod 23 = 18$
• $10^7 = 10^4 \cdot 10^2 \cdot 10^1 = 18 \cdot 8 \cdot 10 = 1440 \bmod 23 = 1440 - 62 \times 23 = 1440 - 1426 = 14$

Compute $14^{-1} \bmod 23$:

• Using extended Euclidean algorithm: $14^{-1} \bmod 23 = 5$ (because $14 \times 5 = 70 \equiv 1 \pmod{23}$)

Therefore: $m' = 7 \cdot 5 \bmod 23 = 35 \bmod 23 = 12$

Verification successful: $m' = m = 12$ ✓

---

3.2 Voting Homomorphic Encryption: $[g^b]$, $b \in \{0,1\}$, Draw the Flow

Problem Construction

Problem: Design an ElGamal homomorphic encryption-based voting system, where:

• Vote value $b \in \{0, 1\}$ (0 = against, 1 = support)
• Use homomorphic encryption to encrypt votes: $[g^b]$ represents encryption of $g^b$
• Require drawing the complete voting and tallying flow

Knowledge Point Analysis

ElGamal Homomorphic Encryption:

• If $C_1 = (g^{r_1}, h^{r_1} \cdot g^{v_1})$ encrypts $g^{v_1}$, $C_2 = (g^{r_2}, h^{r_2} \cdot g^{v_2})$ encrypts $g^{v_2}$
• Then $C_1 \cdot C_2 = (g^{r_1+r_2}, h^{r_1+r_2} \cdot g^{v_1+v_2})$ encrypts $g^{v_1+v_2}$
• This is multiplicative homomorphism (addition in exponent)

Voting Flow:

1. Setup phase: Generate key pair
2. Voting phase: Each voter encrypts vote
3. Aggregation phase: Aggregate all ciphertexts
4. Tallying phase: Decrypt aggregated result

Standard Answer

Flow Diagram:

┌─────────────────────────────────────────────────────────────┐
│                    Voting System Flow                        │
└─────────────────────────────────────────────────────────────┘

[Phase 1: System Setup]
┌─────────────┐
│ Tally Center│
│ (Tally)     │
└─────────────┘
      │
      │ 1. Generate key pair
      │    - Select private key x ∈ Zq
      │    - Compute public key h = g^x
      │
      ▼
┌─────────────┐
│ Public Params│
│ (G, q, g, h)│
└─────────────┘
      │
      │ 2. Broadcast public key
      │
      ▼

[Phase 2: Voting Phase]
┌─────────────┐      ┌─────────────┐      ┌─────────────┐
│ Voter 1     │      │ Voter 2     │      │ Voter N     │
│ (Voter 1)   │      │ (Voter 2)   │  ... │ (Voter N)   │
└─────────────┘      └─────────────┘      └─────────────┘
      │                    │                    │
      │ 3. Select vote      │ 3. Select vote    │ 3. Select vote
      │    b₁ ∈ {0,1}      │    b₂ ∈ {0,1}      │    bₙ ∈ {0,1}
      │                    │                    │
      │ 4. Encrypt vote    │ 4. Encrypt vote   │ 4. Encrypt vote
      │    - Select r₁     │    - Select r₂    │    - Select rₙ
      │    - C₁ = (g^r₁,   │    - C₂ = (g^r₂,   │    - Cₙ = (g^rₙ,
      │         h^r₁·g^b₁) │         h^r₂·g^b₂) │         h^rₙ·g^bₙ)
      │                    │                    │
      ▼                    ▼                    ▼
┌─────────────────────────────────────────────────────────┐
│              Ballot Box (All Ciphertexts)                │
│  C₁, C₂, ..., Cₙ                                        │
└─────────────────────────────────────────────────────────┘

[Phase 3: Aggregation Phase]
┌─────────────┐
│ Tally Center│
└─────────────┘
      │
      │ 5. Aggregate ciphertexts
      │    C_agg = (C₁ · C₂ · ... · Cₙ)
      │    = (g^R_total, h^R_total · g^V_total)
      │    where R_total = Σrᵢ, V_total = Σbᵢ
      │
      ▼

[Phase 4: Tallying Phase]
┌─────────────┐
│ Tally Center│
│ (using sk x)│
└─────────────┘
      │
      │ 6. Decrypt aggregated result
      │    - Compute s = (g^R_total)^x = h^R_total
      │    - Compute g^V_total = (h^R_total·g^V_total) / h^R_total
      │
      │ 7. Compute discrete logarithm
      │    - V_total = log_g(g^V_total)
      │    - Use brute force search (because V_total ≤ N)
      │
      ▼
┌─────────────┐
│ Voting Result│
│ V_total     │
│ (Total Yes) │
└─────────────┘

Detailed Step Description:

Step 1: System Setup

• Tally center selects group $G$ (prime order $q$), generator $g$
• Tally center selects private key $x \in \mathbb{Z}_q$
• Tally center computes public key $h = g^x$
• Public parameters: $(G, q, g, h)$

Step 2: Vote Encryption For each voter $i$:

• Voter selects vote $b_i \in \{0, 1\}$
• Voter selects random number $r_i \in \mathbb{Z}_q$
• Voter computes ciphertext:
  • $c_{1,i} = g^{r_i}$
  • $c_{2,i} = h^{r_i} \cdot g^{b_i}$
• Voter submits ciphertext $C_i = (c_{1,i}, c_{2,i})$

Step 3: Ciphertext Aggregation

• Tally center computes aggregated ciphertext:
  • $c_{1,agg} = \prod_{i=1}^N c_{1,i} = g^{\sum_{i=1}^N r_i} = g^{R_{total}}$
  • $c_{2,agg} = \prod_{i=1}^N c_{2,i} = h^{\sum_{i=1}^N r_i} \cdot g^{\sum_{i=1}^N b_i} = h^{R_{total}} \cdot g^{V_{total}}$
• Where $R_{total} = \sum_{i=1}^N r_i$, $V_{total} = \sum_{i=1}^N b_i$

Step 4: Decryption and Tallying

• Tally center uses private key $x$ to decrypt:
  • Compute $s = c_{1,agg}^x = (g^{R_{total}})^x = h^{R_{total}}$
  • Compute $g^{V_{total}} = \frac{c_{2,agg}}{s} = \frac{h^{R_{total}} \cdot g^{V_{total}}}{h^{R_{total}}} = g^{V_{total}}$
• Compute discrete logarithm: $V_{total} = \log_g(g^{V_{total}})$
• Since $0 \leq V_{total} \leq N$, can use brute force search

---

3.3 Voting Computation: Provide Numbers

Problem Construction

Problem: In the ElGamal voting system, given:

• Group parameters: $p = 23$, $g = 5$, $q = 11$ (order of $g$ is $q$)
• Tally center private key: $x = 3$
• Votes from 3 voters:
  • Voter 1: $b_1 = 1$, $r_1 = 2$
  • Voter 2: $b_2 = 0$, $r_2 = 5$
  • Voter 3: $b_3 = 1$, $r_3 = 7$

Please compute:

1. Public key $h$
2. Each voter's ciphertext $(c_{1,i}, c_{2,i})$
3. Aggregated ciphertext $(c_{1,agg}, c_{2,agg})$
4. Total votes $V_{total}$

Standard Answer

Step 1: Compute Public Key $h$

$h = g^x \bmod p = 5^3 \bmod 23 = 125 \bmod 23 = 10$

Step 2: Compute Each Voter's Ciphertext

Voter 1 ($b_1 = 1$, $r_1 = 2$):

• $c_{1,1} = g^{r_1} \bmod p = 5^2 \bmod 23 = 25 \bmod 23 = 2$
• $c_{2,1} = h^{r_1} \cdot g^{b_1} \bmod p = 10^2 \cdot 5^1 \bmod 23 = 100 \cdot 5 \bmod 23 = 8 \cdot 5 \bmod 23 = 40 \bmod 23 = 17$

Voter 2 ($b_2 = 0$, $r_2 = 5$):

• $c_{1,2} = g^{r_2} \bmod p = 5^5 \bmod 23$
  • $5^2 = 2 \bmod 23$
  • $5^4 = (5^2)^2 = 2^2 = 4 \bmod 23$
  • $5^5 = 5^4 \cdot 5^1 = 4 \cdot 5 = 20 \bmod 23$
• $c_{2,2} = h^{r_2} \cdot g^{b_2} \bmod p = 10^5 \cdot 5^0 \bmod 23 = 10^5 \cdot 1 \bmod 23$
  • $10^2 = 8 \bmod 23$
  • $10^4 = (10^2)^2 = 8^2 = 64 \bmod 23 = 18$
  • $10^5 = 10^4 \cdot 10^1 = 18 \cdot 10 = 180 \bmod 23 = 180 - 7 \times 23 = 180 - 161 = 19$
  • Therefore $c_{2,2} = 19 \bmod 23 = 19$

Voter 3 ($b_3 = 1$, $r_3 = 7$):

• $c_{1,3} = g^{r_3} \bmod p = 5^7 \bmod 23$
  • From previous calculation: $5^7 = 17 \bmod 23$
• $c_{2,3} = h^{r_3} \cdot g^{b_3} \bmod p = 10^7 \cdot 5^1 \bmod 23$
  • $10^7 = 10^5 \cdot 10^2 = 19 \cdot 8 = 152 \bmod 23 = 152 - 6 \times 23 = 152 - 138 = 14$
  • Therefore $c_{2,3} = 14 \cdot 5 = 70 \bmod 23 = 70 - 3 \times 23 = 70 - 69 = 1$

Step 3: Compute Aggregated Ciphertext

$c_{1,agg} = c_{1,1} \cdot c_{1,2} \cdot c_{1,3} \bmod p = 2 \cdot 20 \cdot 17 \bmod 23 = 680 \bmod 23 = 680 - 29 \times 23 = 680 - 667 = 13$

$c_{2,agg} = c_{2,1} \cdot c_{2,2} \cdot c_{2,3} \bmod p = 17 \cdot 19 \cdot 1 \bmod 23 = 323 \bmod 23 = 323 - 14 \times 23 = 323 - 322 = 1$

Step 4: Decrypt and Compute Total Votes

Decryption:

• $s = c_{1,agg}^x \bmod p = 13^3 \bmod 23$
  • $13^2 = 169 \bmod 23 = 169 - 7 \times 23 = 169 - 161 = 8$
  • $13^3 = 13^2 \cdot 13^1 = 8 \cdot 13 = 104 \bmod 23 = 104 - 4 \times 23 = 104 - 92 = 12$
• $g^{V_{total}} = \frac{c_{2,agg}}{s} \bmod p = \frac{1}{12} \bmod 23$

Compute $12^{-1} \bmod 23$:

• Using extended Euclidean algorithm: $12^{-1} \bmod 23 = 2$ (because $12 \times 2 = 24 \equiv 1 \pmod{23}$)

Therefore: $g^{V_{total}} = 1 \cdot 2 = 2 \bmod 23$

Compute Discrete Logarithm:

• Need to find $V_{total}$ such that $g^{V_{total}} = 5^{V_{total}} \equiv 2 \pmod{23}$
• Try: $5^0 = 1$, $5^1 = 5$, $5^2 = 2$ ✓
• Therefore $V_{total} = 2$

Verification:

• $V_{total} = b_1 + b_2 + b_3 = 1 + 0 + 1 = 2$ ✓

Result Summary:

• Public key: $h = 10$
• Voter 1 ciphertext: $(2, 17)$
• Voter 2 ciphertext: $(20, 19)$
• Voter 3 ciphertext: $(17, 1)$
• Aggregated ciphertext: $(13, 1)$
• Total votes: $V_{total} = 2$ (2 yes votes, 1 no vote)

---

3.4 If Someone Lies: Use ZK Proof that Their $b$ is Not 0,1

Problem Construction

Problem: In the ElGamal voting system, malicious voters may try to encrypt values other than 0 or 1 (e.g., $b = 5$) to manipulate results. Design a zero-knowledge proof protocol that proves a voter's ciphertext $C = (c_1, c_2)$ encrypts 0 or 1, without revealing which one. If a voter lies ($b \notin \{0,1\}$), the proof should fail.

Knowledge Point Analysis

OR Proof:

• Need to prove: $(g, h, c_1, c_2)$ is a Diffie-Hellman tuple OR $(g, h, c_1, c_2 \cdot g^{-1})$ is a Diffie-Hellman tuple
• If $b = 0$, then $c_2 = h^r$, so $(g, h, c_1, c_2)$ is a DH tuple
• If $b = 1$, then $c_2 = h^r \cdot g$, so $c_2 \cdot g^{-1} = h^r$, therefore $(g, h, c_1, c_2 \cdot g^{-1})$ is a DH tuple

Standard Answer

Protocol Design:

Public Input: $(g, h, c_1, c_2)$

Prover's Secret: $r$ (such that $c_1 = g^r$)

Prover's Goal: Prove $b \in \{0, 1\}$, i.e.:

• Case 1: $b = 0$, then $(g, h, c_1, c_2)$ is a Diffie-Hellman tuple
• Case 2: $b = 1$, then $(g, h, c_1, c_2 \cdot g^{-1})$ is a Diffie-Hellman tuple

Protocol Steps:

Step 1: Commit

The prover needs to generate commitments for both cases:

For the real case (assume $b = 0$, i.e., $(g, h, c_1, c_2)$ is a Diffie-Hellman tuple):

• Prover knows $r$ such that $c_1 = g^r$ and $c_2 = h^r$
• Prover selects random number $k_0 \leftarrow \mathbb{Z}_q$
• Compute commitment: $a_0 = g^{k_0}$, $b_0 = h^{k_0}$
• Send $(a_0, b_0)$ to verifier

For the simulated case ($b = 1$ case):

• Prover does not know $r'$ such that $c_1 = g^{r'}$ and $c_2 \cdot g^{-1} = h^{r'}$
• Prover selects random number $k_1 \leftarrow \mathbb{Z}_q$ and random challenge $c_1 \leftarrow \mathbb{Z}_q$
• Compute simulated response: $z_1 \leftarrow \mathbb{Z}_q$
• Compute simulated commitment: $a_1 = g^{z_1} \cdot c_1^{-c_1}$, $b_1 = h^{z_1} \cdot (c_2 \cdot g^{-1})^{-c_1}$
• Send $(a_1, b_1)$ to verifier

Step 2: Challenge

Verifier selects random challenge $c \leftarrow \mathbb{Z}_q$, sends to prover.

Step 3: Response

Prover needs to distribute challenge:

For the real case ($b = 0$):

• Prover sets: $c_0 = c - c_1 \pmod{q}$
• Compute response: $z_0 = k_0 + c_0 \cdot r \pmod{q}$
• Send $(c_0, z_0, c_1, z_1)$ to verifier

For the simulated case ($b = 1$):

• If $b = 1$, then prover knows $r$ such that $c_1 = g^r$ and $c_2 \cdot g^{-1} = h^r$
• Similarly, prover will generate real proof for $v = 1$ case and simulated proof for $v = 0$ case

Step 4: Verify

Verifier checks:

1. Challenge Distribution: $c_0 + c_1 \equiv c \pmod{q}$

2. For Case 0 ($(g, h, c_1, c_2)$ is a Diffie-Hellman tuple):

   • $g^{z_0} = a_0 \cdot c_1^{c_0}$
   • $h^{z_0} = b_0 \cdot c_2^{c_0}$

3. For Case 1 ($(g, h, c_1, c_2 \cdot g^{-1})$ is a Diffie-Hellman tuple):

   • $g^{z_1} = a_1 \cdot c_1^{c_1}$
   • $h^{z_1} = b_1 \cdot (c_2 \cdot g^{-1})^{c_1}$

If all checks pass, verifier accepts the proof.

If Someone Lies ($b \notin \{0,1\}$):

• Voter cannot generate real proof for $b = 0$ or $b = 1$
• Can only generate two simulated proofs
• But simulated proofs cannot pass verification (because challenge distribution is incorrect)
• Verifier detects invalid proof and rejects vote

---

Problem 4: Schnorr Signature Insecurity Proof

4.1 Prove Schnorr Signature Insecurity: (R, Z) Inverse Cancellation

Problem Construction

Problem: In a variant of Schnorr signature, if the signature is $(R, Z)$ instead of $(R, s)$, where $Z = s^{-1} \bmod q$ (modular inverse of $s$), prove that this variant is insecure.

Given standard Schnorr signature:

• Signature generation: $s = r + cx \bmod q$, signature is $(R, s)$, where $R = g^r$
• Verification: Check $g^s = R \cdot y^c$

Variant signature:

• Signature generation: $s = r + cx \bmod q$, $Z = s^{-1} \bmod q$, signature is $(R, Z)$
• Verification: Need to derive verification equation

Knowledge Point Analysis

Standard Form of Schnorr Signature:

• Signature: $(R, s)$, where $R = g^r$, $s = r + cx \bmod q$
• Verification: $g^s = R \cdot y^c$

Security Issues of Variant:

• If signature is $(R, Z)$ where $Z = s^{-1}$, attacker may forge signatures by manipulating $Z$
• Key issue: How to recover $s$ from $Z$, and how to modify verification equation

Standard Answer

Derivation of Variant Signature Verification Equation:

Since $Z = s^{-1} \bmod q$, we have $s = Z^{-1} \bmod q$.

Standard verification equation: $g^s = R \cdot y^c$

Substitute $s = Z^{-1}$: $g^{Z^{-1}} = R \cdot y^c$

Raise both sides to the $Z$-th power: $(g^{Z^{-1}})^Z = (R \cdot y^c)^Z$

That is: $g = (R \cdot y^c)^Z = R^Z \cdot y^{cZ}$

Therefore, the variant's verification equation is: $g = R^Z \cdot y^{cZ}$

Attack Method: Inverse Cancellation Attack

Attack Scenario:

• Attacker $A$ observes two valid signatures: $(R_1, Z_1)$ and $(R_2, Z_2)$
• Both signatures are for different messages $m_1$ and $m_2$, but use the same random number $r$ (i.e., $R_1 = R_2 = R = g^r$)

Attack Steps:

Step 1: Observe Two Signatures

• Signature 1: $(R, Z_1)$, where $Z_1 = s_1^{-1}$, $s_1 = r + c_1 x \bmod q$
• Signature 2: $(R, Z_2)$, where $Z_2 = s_2^{-1}$, $s_2 = r + c_2 x \bmod q$
• Note: $R$ is the same, meaning $r$ is the same

Step 2: Exploit Inverse Relationship

Since $Z_1 = s_1^{-1}$ and $Z_2 = s_2^{-1}$, we have:

• $s_1 = Z_1^{-1} \bmod q$
• $s_2 = Z_2^{-1} \bmod q$

Step 3: Compute Private Key $x$

From the two signatures:

• $s_1 = r + c_1 x \bmod q$
• $s_2 = r + c_2 x \bmod q$

Compute $s_1 - s_2$: $s_1 - s_2 = (r + c_1 x) - (r + c_2 x) = (c_1 - c_2) x \pmod{q}$

If $c_1 \neq c_2$, then: $x = (s_1 - s_2) \cdot (c_1 - c_2)^{-1} \pmod{q}$

Since $s_1 = Z_1^{-1}$ and $s_2 = Z_2^{-1}$: $x = (Z_1^{-1} - Z_2^{-1}) \cdot (c_1 - c_2)^{-1} \pmod{q}$

Step 4: Attack Successful

Once the attacker obtains private key $x$, they can forge signatures for any message.

Why the Variant is Insecure:

1. Inverse Operation Breaks Security: Using $Z = s^{-1}$ instead of $s$ allows attackers to extract private keys by observing multiple signatures
2. Nonce Reuse More Easily Exploited: Even if $r$ is reused, standard Schnorr signature requires two different challenges to extract private key; but in the variant, the inverse relationship makes attacks easier
3. Verification Equation Problem: The product relationship between $Z$ and $c$ in verification equation $g = R^Z \cdot y^{cZ}$ may be exploited

Conclusion: The variant using $(R, Z)$ where $Z = s^{-1}$ is insecure, because attackers can recover private keys by observing multiple signatures and exploiting the inverse relationship.

---

4.2 $r$ Only Takes Values from $\{r_1, r_2, r_3\}$, Prove Insecurity

Problem Construction

Problem: In Schnorr signature, if random number $r$ is not uniformly selected from the entire $\mathbb{Z}_q$, but only from a small set $\{r_1, r_2, r_3\}$, prove that this variant is insecure.

Given:

• Standard Schnorr signature: $s = r + cx \bmod q$, signature is $(R, s)$, where $R = g^r$
• Variant: $r$ only selected from $\{r_1, r_2, r_3\}$

Knowledge Point Analysis

Importance of Random Number Space:

• In Schnorr signature, $r$ must be uniformly selected from the entire $\mathbb{Z}_q$
• If $r$'s space is small, attackers can brute force search $r$ to recover private key

Small Space Attack:

• If $r$ has only 3 possible values, attacker only needs to try 3 times to find the correct $r$
• Once $r$ is found, private key can be extracted from signature

Standard Answer

Attack Method: Small Space Brute Force Search

Attack Scenario:

• Attacker $A$ knows signer only selects $r$ from $\{r_1, r_2, r_3\}$
• Attacker can query signature oracle to obtain signature $(R, s)$ for message $m$

Attack Steps:

Step 1: Query Signature

• Attacker queries signature for message $m$, obtains $(R, s)$
• Where $R = g^r$, $s = r + cx \bmod q$, $c = H(m || R)$

Step 2: Brute Force Search $r$

Since $r \in \{r_1, r_2, r_3\}$, attacker tries all possible values:

For each $r_i \in \{r_1, r_2, r_3\}$:

1. Compute $R_i = g^{r_i} \bmod p$
2. If $R_i = R$, then found the used $r_i$

Step 3: Recover Private Key $x$

Once $r_i$ is found, from signature equation: $s = r_i + cx \bmod q$

Therefore: $x = (s - r_i) \cdot c^{-1} \bmod q$

Step 4: Attack Successful

After obtaining private key $x$, attacker can forge signatures for any message.

Success Probability Analysis:

Standard Case ($r$ selected from entire $\mathbb{Z}_q$):

• $r$ has $q$ possible values ($q$ is large, e.g., $2^{256}$)
• Attacker needs to try $q$ times, success probability is $1/q$ (negligible)

Variant Case ($r$ only selected from $\{r_1, r_2, r_3\}$):

• $r$ has only 3 possible values
• Attacker only needs to try 3 times, success probability is $1$ (after querying enough times)

Computational Complexity:

Standard Case:

• Time complexity: $O(q)$ (infeasible, because $q$ is large)
• Success probability: Negligible

Variant Case:

• Time complexity: $O(3) = O(1)$ (constant time)
• Success probability: $1$ (after one query)

Conclusion:

• If $r$ is only selected from $\{r_1, r_2, r_3\}$, attacker can recover private key in constant time
• Therefore, this variant is insecure
• Key Lesson: Schnorr signature requires $r$ to be uniformly selected from the entire $\mathbb{Z}_q$, any restriction on $r$'s space breaks security

---

Problem 5: Zero-Knowledge Proof

5.1 ZK AND Proof (Describe What Type of Proof It Is)

Problem Construction

Problem: Given a diagram of an AND proof (original PPT diagram), describe what type of proof this is and explain how it works.

Knowledge Point Analysis

Basic Concept of AND Proof:

• AND proof is used to prove that prover knows multiple secrets simultaneously
• For example: Prove knowledge of $x_1$ and $x_2$ such that $y_1 = g_1^{x_1}$ and $y_2 = g_2^{x_2}$

Protocol Structure of AND Proof:

• This is a Sigma protocol (3-round interactive protocol)
• Contains: Commit, Challenge, Response

Standard Answer

Proof Type:

This is a Zero-Knowledge AND Proof, used to prove that the prover knows two discrete logarithms simultaneously.

Specifically:

• Prover wants to prove: Know $x_1$ and $x_2$ such that $y_1 = g_1^{x_1}$ and $y_2 = g_2^{x_2}$
• This is a Proof of Knowledge, proving that the prover "possesses" this knowledge
• It is also Zero-Knowledge, verifier cannot obtain information about $x_1$ and $x_2$

Protocol Description (based on standard AND proof):

Public Input: $(g_1, g_2, y_1, y_2)$

Prover's Secret: $(x_1, x_2)$

Protocol Steps:

1. Commit:

   • Prover selects random numbers $r_1, r_2 \leftarrow \mathbb{Z}_q$
   • Prover computes: $a_1 = g_1^{r_1}$, $a_2 = g_2^{r_2}$
   • Prover sends $(a_1, a_2)$ to verifier

2. Challenge:

   • Verifier selects random challenge $c \leftarrow \mathbb{Z}_q$
   • Verifier sends $c$ to prover

3. Response:

   • Prover computes: $z_1 = r_1 + cx_1 \bmod q$, $z_2 = r_2 + cx_2 \bmod q$
   • Prover sends $(z_1, z_2)$ to verifier

4. Verify:

   • Verifier checks:
     • $g_1^{z_1} = a_1 \cdot y_1^c$
     • $g_2^{z_2} = a_2 \cdot y_2^c$
   • If both checks pass, verifier accepts proof

Key Properties:

1. AND Property: Must satisfy both relations simultaneously, neither can be missing
2. Proof of Knowledge: If prover does not know $x_1$ or $x_2$, cannot pass verification
3. Zero-Knowledge: Verifier cannot obtain information about $x_1$ and $x_2$ from the proof process

---

5.2 ZK Soundness Proof (Prove AND Proof Satisfies Soundness Property)

Problem Construction

Problem: Prove that the AND proof in zero-knowledge proof satisfies the Soundness property.

Given: Prover wants to prove knowledge of $x_1$ and $x_2$ such that $y_1 = g_1^{x_1}$ and $y_2 = g_2^{x_2}$.

Please prove: If prover does not know $x_1$ or $x_2$, then verifier rejects the proof with high probability.

Knowledge Point Analysis

Definition of Soundness:

• If prover does not know the secret, verifier rejects proof with high probability
• Formal: $\Pr[\text{Verifier accepts} | \text{Prover does not know secret}] \leq \epsilon$, where $\epsilon$ is a negligible function

Soundness of AND Proof:

• Must know both $x_1$ and $x_2$ to pass verification
• If does not know $x_1$ or $x_2$, cannot construct valid response

Standard Answer

AND Proof Protocol Review:

Protocol Steps:

1. Commit: Prover sends $(a_1, a_2)$, where $a_1 = g_1^{r_1}$, $a_2 = g_2^{r_2}$, $r_1, r_2 \leftarrow \mathbb{Z}_q$
2. Challenge: Verifier sends $c \leftarrow \mathbb{Z}_q$
3. Response: Prover sends $(z_1, z_2)$, where $z_1 = r_1 + cx_1 \bmod q$, $z_2 = r_2 + cx_2 \bmod q$
4. Verify: Verifier checks $g_1^{z_1} = a_1 \cdot y_1^c$ and $g_2^{z_2} = a_2 \cdot y_2^c$

Soundness Proof:

Proof Idea:

Use proof by contradiction: Assume there exists an attacker that can pass verification with non-negligible probability, even without knowing $x_1$ or $x_2$. We will prove this contradicts the hardness of the discrete logarithm problem.

Case Analysis:

Case 1: Prover Does Not Know $x_1$

Assume prover does not know $x_1$, but knows $x_2$.

Attacker Strategy:

• Attacker can correctly compute $z_2 = r_2 + cx_2$ (because knows $x_2$)
• But cannot correctly compute $z_1 = r_1 + cx_1$ (because does not know $x_1$)

Verification Failure Analysis:

• Verifier checks: $g_1^{z_1} = a_1 \cdot y_1^c$
• If attacker does not know $x_1$, cannot compute correct $z_1$
• Assume attacker guesses $z_1'$, then: $g_1^{z_1'} \neq a_1 \cdot y_1^c = g_1^{r_1} \cdot (g_1^{x_1})^c = g_1^{r_1 + cx_1}$
• Verification failure probability: $\Pr[\text{Verification fails}] \geq 1 - \epsilon$, where $\epsilon$ is negligible

Case 2: Prover Does Not Know $x_2$

Similarly, if prover does not know $x_2$, cannot correctly compute $z_2$, verification fails.

Case 3: Prover Does Not Know $x_1$ and $x_2$

If prover knows neither $x_1$ nor $x_2$, cannot correctly compute $z_1$ and $z_2$, verification must fail.

Formal Proof:

Assumption: There exists attacker $A$ that can pass verification with non-negligible probability $\delta$, even without knowing $x_1$ or $x_2$.

Construct Algorithm $B$ to Solve Discrete Logarithm Problem:

Given discrete logarithm problem instance: $(g_1, y_1)$, compute $x_1 = \log_{g_1} y_1$.

Algorithm $B$:

1. Set $g_2$ and $y_2 = g_2^{x_2}$ ($B$ knows $x_2$)
2. Run AND proof protocol as verifier
3. If attacker $A$ passes verification, extract information from response

Key Observation:

• If $A$ can pass verification, then $g_1^{z_1} = a_1 \cdot y_1^c$
• That is $g_1^{z_1} = g_1^{r_1} \cdot y_1^c$
• Therefore $z_1 = r_1 + c \cdot \log_{g_1} y_1 \bmod q$
• If $B$ knows $r_1$ and $c$, can compute: $\log_{g_1} y_1 = (z_1 - r_1) \cdot c^{-1} \bmod q$

Problem: $B$ does not know $r_1$ (because $a_1 = g_1^{r_1}$ is sent by attacker)

Use Rewinding Technique:

1. $B$ runs protocol, obtains $(a_1, a_2)$, sends challenge $c$, obtains $(z_1, z_2)$
2. $B$ rewinds protocol, uses same $(a_1, a_2)$, but sends different challenge $c'$
3. If $A$ passes verification again, obtains $(z_1', z_2')$
4. From two responses:
   • $z_1 = r_1 + cx_1 \bmod q$
   • $z_1' = r_1 + c'x_1 \bmod q$
   • Therefore: $z_1 - z_1' = (c - c')x_1 \bmod q$
   • If $c \neq c'$, then: $x_1 = (z_1 - z_1') \cdot (c - c')^{-1} \bmod q$

Success Probability:

• If $A$ can pass verification with probability $\delta$
• Then $B$ can solve discrete logarithm problem with probability at least $\delta^2$
• If $\delta$ is non-negligible, then $\delta^2$ is also non-negligible
• This contradicts the hardness of discrete logarithm problem

Conclusion:

• If prover does not know $x_1$ or $x_2$, cannot generate valid AND proof
• Verifier rejects proof with probability $\geq 1 - \epsilon$, where $\epsilon$ is a negligible function
• Therefore, AND proof satisfies Soundness property

---

5.3 ZK OR Proof: Prove Alice Has One of $[g_1, g_2]$ and One of $[g_3, g_4]$

Problem Construction

Problem: Design a zero-knowledge OR proof that proves Alice has one of the following knowledge:

• Know $x_1$ such that $y_1 = g_1^{x_1}$ OR know $x_2$ such that $y_2 = g_2^{x_2}$
• AND know $x_3$ such that $y_3 = g_3^{x_3}$ OR know $x_4$ such that $y_4 = g_4^{x_4}$

That is: Alice has one discrete logarithm of $[g_1, g_2]$ AND one discrete logarithm of $[g_3, g_4]$.

Knowledge Point Analysis

Basic Idea of OR Proof:

• OR proof is used to prove knowledge of one of multiple relations
• For unknown relations, use simulated proof
• Use forking technique to distribute challenge

Composite OR Proof:

• This problem needs to prove: $(g_1 \text{ OR } g_2) \text{ AND } (g_3 \text{ OR } g_4)$
• This can be decomposed as: Generate proof for each OR relation, then combine

Standard Answer

Protocol Design:

Public Input: $(g_1, g_2, g_3, g_4, y_1, y_2, y_3, y_4)$

Prover's Secret:

• Alice knows $x_i$ such that $y_i = g_i^{x_i}$, where $i \in \{1,2\}$ is one AND $j \in \{3,4\}$ is one
• Assume Alice knows $x_1$ and $x_3$ (other cases similar)

Protocol Steps:

Step 1: Commit

Alice needs to generate commitments for four relations:

For Real Relations ($g_1$ and $g_3$):

• Alice knows $x_1$ such that $y_1 = g_1^{x_1}$
• Alice knows $x_3$ such that $y_3 = g_3^{x_3}$
• Alice selects random numbers $r_1, r_3 \leftarrow \mathbb{Z}_q$
• Alice computes: $a_1 = g_1^{r_1}$, $a_3 = g_3^{r_3}$
• Alice sends $(a_1, a_3)$ to verifier

For Simulated Relations ($g_2$ and $g_4$):

• Alice does not know $x_2$ and $x_4$
• Alice selects random numbers $r_2, r_4 \leftarrow \mathbb{Z}_q$ and random challenges $c_2, c_4 \leftarrow \mathbb{Z}_q$
• Alice computes simulated responses: $z_2, z_4 \leftarrow \mathbb{Z}_q$
• Alice computes simulated commitments:
  • $a_2 = g_2^{z_2} \cdot y_2^{-c_2}$
  • $a_4 = g_4^{z_4} \cdot y_4^{-c_4}$
• Alice sends $(a_2, a_4, c_2, c_4)$ to verifier

Step 2: Challenge

Verifier selects random challenge $c \leftarrow \mathbb{Z}_q$, sends to Alice.

Step 3: Response

Alice needs to distribute challenge:

For Real Relations ($g_1$ and $g_3$):

• Alice sets: $c_1 = c - c_2 \pmod{q}$, $c_3 = c - c_4 \pmod{q}$
• Alice computes responses:
  • $z_1 = r_1 + c_1 \cdot x_1 \pmod{q}$
  • $z_3 = r_3 + c_3 \cdot x_3 \pmod{q}$
• Alice sends $(c_1, z_1, c_3, z_3)$ to verifier

For Simulated Relations ($g_2$ and $g_4$):

• Alice has already sent $(c_2, z_2, c_4, z_4)$

Step 4: Verify

Verifier checks:

1. Challenge Distribution:

   • $c_1 + c_2 \equiv c \pmod{q}$
   • $c_3 + c_4 \equiv c \pmod{q}$

2. For $g_1$ Relation (if Alice knows $x_1$):

   • $g_1^{z_1} = a_1 \cdot y_1^{c_1}$

3. For $g_2$ Relation (simulated):

   • $g_2^{z_2} = a_2 \cdot y_2^{c_2}$

4. For $g_3$ Relation (if Alice knows $x_3$):

   • $g_3^{z_3} = a_3 \cdot y_3^{c_3}$

5. For $g_4$ Relation (simulated):

   • $g_4^{z_4} = a_4 \cdot y_4^{c_4}$

If all checks pass, verifier accepts proof.

Complete Protocol Flow:

1. Alice → Verifier: $(a_1, a_2, a_3, a_4, c_2, c_4)$ (commitments and partial challenges)

2. Verifier → Alice: $c$ (random challenge)

3. Alice → Verifier: $(c_1, z_1, z_2, c_3, z_3, z_4)$ (challenge distribution and responses)

4. Verifier Verifies:

   • $c_1 + c_2 \equiv c \pmod{q}$ and $c_3 + c_4 \equiv c \pmod{q}$
   • $g_1^{z_1} = a_1 \cdot y_1^{c_1}$ and $g_2^{z_2} = a_2 \cdot y_2^{c_2}$
   • $g_3^{z_3} = a_3 \cdot y_3^{c_3}$ and $g_4^{z_4} = a_4 \cdot y_4^{c_4}$

Security:

• Completeness: If Alice knows $x_1$ and $x_3$ (or corresponding combinations), honest Alice can always pass verification
• Soundness: If Alice does not know one of $[g_1, g_2]$ OR does not know one of $[g_3, g_4]$, cannot pass verification
• Zero-Knowledge: Verifier cannot know whether Alice knows $g_1$ or $g_2$, and whether $g_3$ or $g_4$

Key Observations:

1. AND Combination: Must satisfy both OR relations simultaneously
2. OR Proof: Each OR relation uses standard OR proof technique
3. Challenge Distribution: Use forking technique to ensure correct challenge distribution

---

Summary

Key Knowledge Points Review

1. Concept Explanation: Basic concepts and applications of Hash Function, 1-n OT, IBE, MPC
2. Scheme Design: Large file transfer, payment confidentiality, integrity, access control
3. ElGamal Voting: Homomorphic encryption, ciphertext aggregation, zero-knowledge proof
4. Schnorr Signature Security: Inverse attack, small space attack
5. Zero-Knowledge Proof: AND proof, OR proof, Soundness proof

Exam Answering Tips

1. Concept Questions: Answer according to Form, Background, Scenario, Benefit structure
2. Scheme Design Questions: Clearly state tool selection, detailed process, explain how each requirement is satisfied
3. Computation Questions: Clear steps, verify results
4. Proof Questions: Rigorous logic, use proof by contradiction or reduction techniques