Can someone please explain how frost key rotation actually works, and if there are any security proofs for it?
#asknostr
Discussion
nostr:npub1gg5uy8cpqx4u8wj9yvlpwm5ht757vudmrzn8y27lwunt5f2ytlusklulq3 nostr:npub1s9etjgzjglwlaxdhsveq0qksxyh6xpdpn8ajh69ruetrug957r3qpklxzl
From nostr:npub17u5dneh8qjp43ecfxr6u5e9sjamsmxyuekrg2nlxrrk6nj9rsyrqywt4tp ‘s AI chat on his website:
“FROST (Flexible Round-Optimized Schnorr Threshold Signatures) is a cryptographic protocol designed for threshold signing, where a group of participants collectively produces a single signature. While FROST itself doesn't inherently include a "key rotation" mechanism, the concept of key rotation in a threshold setup can be implemented by updating the key shares and public keys used in the protocol.
In a multisig or threshold scheme like FROST, key rotation typically involves generating a new set of private key shares and a corresponding public key. The process might look like this:
Key Generation: A new threshold key pair is generated. This involves creating a new private key and splitting it into shares for the participants, ensuring the same threshold (e.g., 2-of-3 or 3-of-5) is maintained.
Share Distribution: The new private key shares are securely distributed to the participants. This step requires a secure communication channel to prevent interception or tam secure transfer. Participants replace their old shares with the new ones.
Public Key Update: The new public key, derived from the new private key shares, is shared with all participants and used for future signing operations.
Transaction Migration: If the old key was associated with specific Bitcoin addresses, funds may need to be transferred to new addresses derived from the updated key.
Key rotation in threshold schemes like FROST enhances security by invalidating old keys, mitigating risks from compromised shares, and ensuring the system remains resilient. However, the exact implementation depends on the specific use case and software supporting the protocol. If you're looking for practical examples, Casa's multisig wallet offers a user-friendly approach to key rotation, albeit not using FROST specifically.”
Yes exactly. I asked about this and got a very duhdoy frost just HAS key rotation type of response so I had to dig a bit myself.
FROST is not exempt from requiring some central coordinator to facilitate a rotation. I suspect that in the use case we are talking about, i.e. an nsec bunker type setup, when one key is compromised, the user destroys the others and regenerates a new set of keys.
This doesn't stop someone who managed to discover two of your keys. This type of key rotation does not affect them at all.
Someone correct me if I'm wrong.
Every time you split your nsec into shares, those shares are part of a unique set. If a share in the set is compromised, you delete the other shares and abandon the whole set. That renders the compromised share useless. Then you generate a new set of shares, and replace the old set. Rinse and repeat.
Thanks.
And an old share can be kept in the new set?
Do we have security proof for this yet?
Literal Shamir's secret sharing?
Do you have some pseudo code for this please?
Shares do not work between sets, so the old shares will not work in the new set.
We are using shamir's secret sharing for splitting your nsec, which does have security proofs afaik.
Would be interesting to see a proof for the combination of SSS with the Schnorr signature part, especislly in relation to key rotation.
This does sound like there is some footgun possibility there.