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

Do we need a protocol to generate auxiliary data? #98

Open
fjarri opened this issue Jan 17, 2024 · 0 comments
Open

Do we need a protocol to generate auxiliary data? #98

fjarri opened this issue Jan 17, 2024 · 0 comments
Labels
cryptography Needs cryptographic expertise
Milestone

Comments

@fjarri
Copy link
Member

fjarri commented Jan 17, 2024

Why is it necessary to have a whole protocol to generate auxiliary information (RSA primes) for the nodes? Currently, this happens during the key refresh (Fig. 6 in the paper). Note that the actual key refresh and auxiliary data generation can be separated; the auxiliary data generation can be done first, and key refresh uses the Paillier modulus created earlier. They seem to only be bundled in the paper for performance reasons.

What if, instead, each node just independently generated its secret primes p, q, and published N = p*q along with all the ZK proofs ensuring that the prime pair is well-formed? This public information would be available at any time on request, and would be used during the signing protocol execution. The nodes could refresh these parameters whenever they wanted, also independently. What kind of attack vector would that open?

Possible problem: how to create the non-interactive challenge for the ZK proofs in this case? I am not sure what is the secure approach here.

This is related to #31: if one party owns several key shares, it only needs one set of auxiliary parameters. They are not connected to a share but rather to the node's identity.

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

No branches or pull requests

1 participant