Key Refresh Instructions

taurushq-io / multi-party-sig

Implementation of protocols for threshold signatures

Apache License 2.0

311 stars 120 forks source link

Key Refresh Instructions #86

Open codyborn opened 1 year ago

codyborn commented 1 year ago

I'm trying to perform a key refresh with 2/3 original signers and 1 new signer (threshold is set to 1). This would be performed if one of the signers lost their key and it needed to be regenerated. When I try to participate in the key refresh as the new signer using a new config, I get the error round 5: failed to validate schnorr proof for received share. When I use the original ECDSA value from the missing signer in the config, the refresh succeeds. However, since this ECDSA value is a secret, the new signer naturally wouldn't be aware of it. Can you share details on how to properly generate a new config for the new signer to participate in a refresh?

toufic0710 commented 1 year ago

up ! also having issues implementing resharing

johnthethird commented 1 year ago

Unfortunately thats not how the key refresh protocol from the Canetti paper works. If you want to change membership you need to generate an entirely new address with the new parties, and have the old parties xfer the assets to the new address.

The Key Refresh protocol requires all signers to generate the new key material (and the public addr stays the same), and they have to pinky-promise to delete the old key material. The attack vector this is meant to protect against is an adversary slowly gaining access to each signers key material over time. If the whole group refreshes every X days, then the attacker must get all the signers key material within X days. So it just shortens the window of attack.

kobigurk commented 1 year ago

Unfortunately thats not how the key refresh protocol from the Canetti paper works. If you want to change membership you need to generate an entirely new address with the new parties, and have the old parties xfer the assets to the new address.

The Key Refresh protocol requires all signers to generate the new key material (and the public addr stays the same), and they have to pinky-promise to delete the old key material. The attack vector this is meant to protect against is an adversary slowly gaining access to each signers key material over time. If the whole group refreshes every X days, then the attacker must get all the signers key material within X days. So it just shortens the window of attack.

Why wouldn't you be able to run the usual secret redistribution protocols and continue from there as in key generation?

toufic0710 commented 1 year ago

It seems that we are not able to do so only if we follow the Canetti paper, it would be possible if we do not follow the "refresh" section in it.

mathcrypto commented 1 year ago

I assume we can use the key refreshment and make some changes to be able to do the resharing process. In the Key resharing described in Jen Groth paper:

Every participant i in takes their own share si and creates sub-shares si1,si2,........sin' and broadcast these sub-shares to the new set of participants n'.
Each new participant then collects the sub-shares they received and interpolates them into a new share (this will be their share of the master secret s). This process does not change the shares nor the public address associated with the master secret share s The key refreshment process in Canetti paper is very similar. Each participant will take their own share, divide it into sub-shares, computes the public keys from each sub-share, and broadcasts them to the set of participants. If we replace n with n' and send it to the new participants we are able to do resharing on the condition of n=n' I believe it should work. Please correct me if I'm wrong.