You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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 publishedN = 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.
The text was updated successfully, but these errors were encountered: