# 5. Salting / Shifting

## How to prevent anyhow whack A\*B = C

We addressed the problem of encryption and therefore “zer0-knowledge”, through the use of ECC.

At the point you might be wondering, given our earlier explanation of what the verifier does, “why can’t I just submit arbitrary EC points that will clear the equality check after being paired?”.

Alternatively put, the proof generated must be tangibly connected to the original claim of knowledge a.k.a witness values.

So the final problem addressed in this section:

* User can simply invent values a, b, c where ab = c and present them to the verifier
* Or the prover could be malicious and generate a conveniently arbitrary proof for verification.
* Thus, the verifier has no idea if elliptic curve points **\[A]₁**, **\[B]₂**, and **\[C]₁** were the result of a satisfied QAP or made up values.

### **We need to force the prover to be honest**

This is achieved by introducing salting. Salting will prevent made up values from clearing the equality check.

Salting is applied by forcing the prover to shift the EC points **`[A]₁`** and **`[B]`**`₂` by an unknown amount. This shifting is done by adding elliptic curve points **`[αG]`** and **`[βG]`** respectively.

**Implementation: verifier key**

`[αG]` and `[βG]` are created in the trusted setup phase by randomly sampling α and β, creating elliptic curve points \[αG] and \[βG] and then destroying α and β.

This is the earlier mentioned verifier key.

**Verifier key**

* EC points `α[G1]` and `β[G2]`
* created by the trusted setup agent randomly sampling α and β

**The updated \[A] and \[B] points would be:**

$$
[A]_1 = [A_{old}]_1 + [α]_1
\newline
[B]_2 = [B_{old}]_2 + [β]_2
$$

The introduction of these random EC points would alter the equality as we previously understood it. Let us visually explore how the equality changes.

<figure><img src="https://1983523492-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F0nwEx8a60yETwfNYnenT%2Fuploads%2FRQnxEhkuI4yeIYnqYXUj%2Fimage.png?alt=media&#x26;token=63ad691c-752c-4a74-8021-c3999a89d076" alt=""><figcaption></figcaption></figure>

Now that you have a clear grasp of how adding salts alters the equality in polynomial form, let us raise it by the corresponding EC points.

<figure><img src="https://1983523492-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F0nwEx8a60yETwfNYnenT%2Fuploads%2FNF3lpR5Q49VXLS2AhJl6%2Fimage.png?alt=media&#x26;token=516468e4-8228-4ac6-bad1-ff40f5c305f8" alt=""><figcaption></figcaption></figure>

As we can see by the last line, the verifier will evaluate the EC point pairing equality taking into consideration the salts.

Note that the \[A], \[B], \[C] points are **NOT** the same \[A], \[B], \[C] points we started with in the beginning - they now account for the added salts.

We choose to keep the naming consistent to avoid unnecessarily introducing new variable names to reduce mental overhead.

***

#### **SUMMARY**

**The prover is given the proving key which comprises of:**

* `α[G1]` and `β[G2]` , which are randomly sampled EC points
* powers of tau

**The verifier is given the verifier key which comprises of:**

* `α[G1]` and `β[G2]`

**The prover creates a proof comprising of EC points:**

* $$[A]_1\space, \space\space [B]_2 \space\space, [C]_1$$
* These EC points account for the random salting introduced to prevent forgery

**The verifier actually calculates:**

$$
pairing([A]_1, [B]_2)  \stackrel{?}{=} pairing([C]_1, [G]_2) + pairing([α]_1, [β]_2)
$$



***

_<mark style="color:blue;">Read more:</mark>_ [_<mark style="color:blue;">https://www.rareskills.io/post/groth16</mark>_](https://www.rareskills.io/post/groth16*)

***
