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

"Fast" vs "Simple" decryption method #5

Closed
Tracked by #76
cygnusv opened this issue Oct 28, 2022 · 1 comment · Fixed by #20
Closed
Tracked by #76

"Fast" vs "Simple" decryption method #5

cygnusv opened this issue Oct 28, 2022 · 1 comment · Fixed by #20
Assignees
Milestone

Comments

@cygnusv
Copy link
Member

cygnusv commented Oct 28, 2022

Ferveo's paper and implementation use what they call a "fast" approach for Threshold Decryption, as opposed to the "Simple" method ("Fast" and "Simple" being the terms used in their docs). The reality is a bit more nuanced and it has implications for us.

The "Fast" method is actually a trade-off where they optimize the threshold decryption step over the combine step. That makes sense for their use case, where Ferveo is used during a block production stage to decrypt encrypted TXs; since in that stage the validator set that decrypts is fixed and reused for many TXs, it makes sense to reduce the individual decryption time, while reusing intermediate computations in the combine step that are depended on the validator set (i.e., Lagrange coefficients). The way to do this is to kick the can down the road at decryption time, so validators don't actually create decryption shares (which would require computing a pairing) but some blinded values (which only require an EC multiplication) that can be later combined with known information from the DKG ritual at the combine step. In short, the implications of the "fast" method are:

  • Optimizing decryption over combination
  • Combination is now heavier (as the pairings you're not doing at decryption time need to be done anyway at combine time) and requires knowledge of some DKG ritual information

The "simple" method is a more balanced approach, where pairings are done at each individual decryption request, and the combination is "merely" a bunch of EC multiplications (although in the much harder group $\mathbb G_T$). For our use case, it makes sense to try to reduce the combine step as much as possible as it will be done by Bob in the browser (potentially by a Porter instance if it's trusted enough).

To me this points towards changing Ferveo to implement the "simple" version, which is also...simpler, as you don't need to introduce this intermediate blinding step. Since they prepare these blinding values at the DKG stage, this also has implications on the DKG implementation.

@piotr-roslaniec
Copy link

piotr-roslaniec commented Nov 4, 2022

Is the "Public verification of decryption shares" paragraph only relevant to the "fast" method?

Looking at how validator's shares and their verification are defined for the "fast" method:
A blinded public key, $$Pi=[b]H$$
A validator's share, $$Di=[b−1]U$$
Verification, $$e(Di,Pi)=e(U,H)$$

Whereas the key share for the "simple" method is defined as:
$$Ci=e(U,Zi)$$

Is this property interesting to us? Should we reconsider using the "fast" method?

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

Successfully merging a pull request may close this issue.

2 participants