[Feature]: Generate recoverable private shares during DKG

[djordon]

Feature - Generate recoverable private shares during DKG

1. Description

Right now, the distributed key generation (DKG) private shares for locking the aggregate key are generated randomly using a cryptographically secure pseudo random number generator (CSPRNG) seeded with OS provided randomness. On linux, we use the getrandom syscall for our randomness. This is great but it comes at a cost; it's impossible for us to recreate the keys if enough signers lose their secret shares.

This ticket proposes that we seed the randomness for DKG keys using the signer's private key along with the chain tip block hash of the canonical bitcoin blockchain.

1.1 Context & Purpose

It's possible for errors to cause many signers to lose their secret shares over time. For example, perhaps some sizable minority of signers have their databases fail. If this were to happen, then the deposited funds would be unspendable. This is bad, so we would like to have some way of recovering the funds in a reasonable amount of time.

The solution proposed here is to open the possibility to recreate the DKG shares. If we seed the random number generator a secure but predictable way, we could re-run DKG and arrive at the DKG shares that were originally generated. This proposal requires all signers to have their original private key and agree to participated in a DKG rerun.

Also, this proposal is not to write the code to re-run DKG, just to give us a path to recovery if we were to need one.

2. Technical Details:

Later versions of WSTS allow the user to specify their random number generator when doing DKG. We can use this feature to use WSTS with a random number generate that has been seeded with whatever we like.

The specific proposal is to use the rand::rngs::StdRng as the random number generator when building a state machine for DKG. That type is a CSPRNG that implements rand_core::SeedableRng, where the seed can be any 32 byte sequence. This ticket proposes that the seed be the SHA256 of the signer's private key with the chain tip block hash of the canonical bitcoin blockchain.

At the time of writing, the code for specifying the random number generators is not on main, but we have a PR at #1265.

2.1 Acceptance Criteria:

• When doing DKG, seed the signer state machine with randomness that incorporates the private key and the bitcoin block hash.

3. Related Issues and Pull Requests (optional):

4. Appendix

We need to make sure that seeding the state machine is robust against variable network conditions. For example, if DKG is rerun and signers get messages in different order than in the first run, we need to make sure that the generated aggregate key is still the same. This should be the case since generating the private polynomial is done first; it happens when creating a new signer state machine. But we should have a test so that this kind of thing is caught if/when we change the state machine, such as for #1286.