Muh Privacy: Separating public and private inputs
Last updated
Was this helpful?
Last updated
Was this helpful?
We shall address how our equation changes to allow for both public and private inputs.
Let’s recap; the prover calculates the following EC points:
And the verifier will calculate pairing( α[G1], β[G2]) and the equality:
Let us split our previously used witness into public and private inputs:
Here we assume that the public inputs are 1 and out; and the rest are private inputs.
Public inputs are handled by the verifier
Private inputs are handled by the prover
As much as we are splitting the witness vector up based on privacy, this only impacts the construction of [C]. [A] and [B] remain unchanged.
[C] is computed over private inputs by the prover
[C] is computed over public inputs by the verifier
This means that the prove computes a fragment of [C] and passes it to the verifier, which then computes the remaining public fragment, obtaining the whole piece; then proceeding to verify the proof.
[C]Note that while we use polynomial expression (W.a and so forth), it should be synonymous with their respective EC point forms.
For the verifier, the summation symbol starts with 0 and ends with 1, indicating the 1st and 2nd term of the witness vector: $a_i: a_0, \space a_1$
: 1
: out
Notice that the prover is responsible for calculating [HT], and the verifier handles [αβ]
Given the new breakdown of [C], the verifier key will have to accommodate the necessary EC data. We will address what the final proving and verifier key are at the end.
There is nothing preventing a malicious prover from using public inputs to, uhh, somehow magically create a valid forged proof.
To negate this attack vector, we introduce another set of greek alphabets: γ and δ.
The verifier fragment of [C] is divided by γ
The prover fragment of [C] is divided by δ
These values are randomly sampled during the trusted phase setup
What this looks like:
Prover generates EC points: [A], [B], [C_private]
Verifier generates EC points: [C_public]
Verifier calculates the 4 bilinear mappings as seen above, and checks for equality
The following values are randomly sampled during the trusted setup phase:
γ, δ, α, β and τ
are communicated as EC points of different groups to the verifier to obfuscate their values.
If the range of values over witness vector variables can take are very small and therefore easily guessable; e.g. a binary variable that only be either 1 or 0.
In such a situation, an attacker can iterate through a list of guesses of proofs to generate a legitimate one.
Solution
The solution is to introduce more greek alphabets - for salting/random shifting, of course.
In this case, we will introduce r and s.
r & s are introduced in the proving phase. (Not trusted setup)
Prover randomly samples 2 field elements.
Both [A] and [B] are shifted with the introduction of r and s; similar to the introduction of alpha and beta
Prover needs to use one of the EC points within the proving key to raise both r and s into EC points themselves; hence the use of [δ]
Obviously with the introduction of new variables we need to balance the equality. Though the question is how:
By this point it should be evident to the reader how sU and rV map to s[A] and r[B].
There might be some initial confusion as to why the last term is - rs[δ] and not perhaps + rs[δ]
This is why:
sU and rV are actually representative of the old [A] and [B] points; pre-shifting with r and s.
Whereas s[A] and r[B] introduced as balancing terms to the RHS, are reflective of the new [A] and [B] points; inclusive of the shifting caused by r and s.
Instead of using the “old” points. we use the new points and negate the extra rs term.
This means we now need a [B] and [δ] in G1, as part of balancing [C] - amongst other additions to the trusted setup phase. We will list the final variables in the next section.
