Use common rlwe encryption script for pk-enc and sk-enc

[Vishalkulkarni45]

1. Made the changes which were mentioned in the previous PR
2. Made a common rlwe encryption function in scripts/utils.py which can be used by both circuit_sk.py and circuit_pk.py
3. Added the Mathematical proof for range check of p2i and p1i in circuit_pk.py
4. Fixed test_sk_enc_valid of sk_encryption_circuit
5. Made changes in test_pk_enc_valid to run circuit using MockProver , fixed test_pk_enc_invalid_range and test_pk_enc_invalid_polys ok pk_encryption_circuit
6. Range checks are performed in there respective scripts , i was not clear whether to build a common function for range check which can be used by both the scripts

[enricobottazzi]

Thanks for the contribution. I'm happy to see that the balance of increased lines of codes has been reduced from the previous PR. But I think this can be further improved. Just by looking at the python files circuit_sk.py and circuit_pk.py you can see a lot of code redundancy. I suggest you to create rlwe.py and think about it as a circuit by itself. Both circuit_sk.py and circuit_pk.py will use this circuit as part of the script:

• for the case of the circuit_sk.py, the circuit rlwe.py contains the whole logic needed so there's nothing much to add except for the logic of consuming the input passed by the user and generating an output
• for the case of circuit_pk.py some further logic can be added to verify the correct formation of the second component of the ciphertext

Please update it first and ping me when done before moving to the rust

Plus for the mathematical proof for the range check of p2i and p1i I meant something similar to the Appendix C of the paper

[Vishalkulkarni45]

My apologies, I have some doubt related to considering rlwe.py as a circuit . To generate the second matrix of the pk_enc as mentioned in page 13 , i decided to used the same rlwe function to generate it by passing the zero polynomial in place of k1 and tested it successfully .By doing this i can reduce the repetition of code but if i consider rlwe.py as a circuit multiplying zero polynomial with another polynomial k0 to generate second matrix adds extra computation ?

Modifying the existed rlwe_encryption function such that it generated both first and second matrix adds additional computation if i see rlwe.py as a circuit or create a new function in rlwe.py which is used to generate only second matrix of pk_enc ?

Thanks for reviewing my code

[enricobottazzi]

I understand your concern. I'm not sure what the best way is to solve the problem. The goal is remove any duplicate code.

[Vishalkulkarni45]

I felt using the same rlwe encryption function to generate the second matrix of pk_enc
If you don't mine can i now move to the Rust part, build common rlwe function for pk_enc_circuit and sk_enc_circuit ?

[enricobottazzi]

I think that there is still a lot of duplicated code in the python part. Getting that right would help shape the Rust part. I suggest to further polish that part before moving to Rust.

[Vishalkulkarni45]

Thanks @enricobottazzi for bearing with me , I created a common function poly_range_check to perform range checks on the coefficients of shifted polynomials. Additionally, I made another common function range_check_ciphertext_formation , which performs range checks at each step of ciphertext formation. These functions are utilized by circuit_sk.py and circuit_pk.py to generate the first matrix as shown on page 13 and moved the rlwe_encryption function to rlwe.py

[enricobottazzi]

Hi @Vishalkulkarni45. I am looking into the PR again. I think you did a good job of removing duplicates.

I realized that at the very core, the operation of public key encryption is basically just a secret key encryption performed twice. I agree that approaching the problem in this way will add some inefficiency as some elements in the calculation of $Ct_{0, i}$ are zero polynomials. But in any case, I think that the benefit of code simplicity outweighs the computation overhead.

In that case, a nice to have would be a proof aggregator that, in the case of public key encryption, merges the two proofs into a single one.

[Vishalkulkarni45]

Thank you @enricobottazzi ,

It seems I have completed the Python script portion, correct?

To minimize code duplication for the circuit part, I need to create a proof aggregator. This aggregator will combine the proofs for ct0i and ct1i of pk_enc circuit.

There's a common function to be built to generate the ct0i proof of the sk_enc circuit and both ct0i and ct1i proofs of pk_enc circuit. Additionally, to compute the ct1i of pk_enc, I need to pass k0 as the zero polynomial to the common function ?.

[enricobottazzi]

Thinking again about this issue, I don't think that this is relevant anymore. Greco as it is right now already have all the necessary components to extend it to public key encryption. I don't think that loading the code base with extra code (which is mostly duplicate of what's already in place for secret key encryption is) is the right approach.
I'm closing the issue for now.