Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ElGamal Pair Sequences #447

Open
lhmerino opened this issue Oct 10, 2020 · 1 comment
Open

ElGamal Pair Sequences #447

lhmerino opened this issue Oct 10, 2020 · 1 comment
Assignees

Comments

@lhmerino
Copy link
Member

lhmerino commented Oct 10, 2020

Kyber currently implements PairShuffle where one can shuffle a list of ElGamal ciphertexts. The goal of this issue is to implement the protocol provided by Andrew Neff in Section 5 of his “Verifiably Mixing (Shuffling) of ElGamal pairs” to shuffle more than one ElGamal pair.

I have implemented a prototype of this protocol but the following needs to be resolved:

  1. In terms of the protocol itself, why does the verifier need to generate a random and independent value (EGAR1)?
  2. In terms of the implementation, how to reliably fetch those values from the verifier before the prover continues onto the next step of the protocol (EGAR2)?
  3. In terms of the implementation, how to integrate the extra proof parameters (XXUp, YYUp, XXDown, YYDown) into the prover context?
@lhmerino lhmerino self-assigned this Oct 10, 2020
@lhmerino lhmerino changed the title k-shuffles of Tuples k-Shuffles of Tuples Oct 10, 2020
@lhmerino lhmerino changed the title k-Shuffles of Tuples ElGamal Pair Sequences Dec 14, 2020
@nkcr
Copy link
Contributor

nkcr commented Dec 15, 2020

I am not very familiar with the current neff shuffle implementation, but here are my "high-level" comments on 2 and 3:

In terms of the implementation, how to reliably fetch those values from the verifier before the prover continues onto the next step of the protocol (EGAR2)?

This should be the responsibility of the one using this library. Kyber provides the functions to generate messages, the synchronization and message passing part is done by the one using kyber (like this is the case for DKG).

In terms of the implementation, how to integrate the extra proof parameters (XXUp, YYUp, XXDown, YYDown) into the prover context?

I guess that if we want to keep backward compatibility, that would be easier if we implement that new version of neff shuffling in a new package. Like so we are free to include whatever parameters needed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants