FROST super issue #85
Description
secp256kfun FROST impl
TODO Notion DKG id
This is useful so we can sign it with pop and in gun to make sure every device displays the same thing before using they key.
TODO Proof of possession
Just use hash type parameter that is passed to internal Schnorr instance. Tag the hash when you init Frost with “frost/dkg”. Then hash all the commitments together to form the dkg-id, use the internal Schnorr (with noncegen) to produce pop.
\#[derive(Clone, Debug, Default)]
pub struct Frost<H, NG = ()> {
schnorr: Schnorr<H, NG>,
dkg_id_hash: H
}TODO How do we make it two rounds in gun
- Problem is we need to negate our own first coef based on the joint key which we don’t know yet.
TODO Have API that allows you to pass in first coef
Need to handle needs negation later:
// X = (b*x) * G where b is 1 or -1.
// Then you tweak
// X' = X + t * G
// if X' needs negation then sk is
// -(b*x + t) = -b*x - t
// new b = -b i.e. prev needs_negation xor new needs_negation.
// Store new join_public_key and new tweak, as well as needs_negation
Stop using needs negation when creating shares.
TODO How should gennonce be designed
pub fn gen_nonce(
&self,
secret: &Scalar,
sid: &[u8]
) -> NonceKeyPair { ... }
Application makes sure sid is unique. Document secret could be either static first coef or secret
share depending on the application – but be consistent!
TODO Renaming things
- s/JointKey/FrostKey/
- s/Dkg/KeyGen/
- s/collectpolys/newkeygen/
- s/FirstRoundError/NewKeyGenError/
- s/collectshares/finishkeygen/
- s/SecondRoundError/FinishKeyGenError/
Don’t use HashMap
Doesn’t work with nostd and introduces non-determinism. Probably just use vec internally and warn users.
Nonce agg scheme what to hash?
No
Do proptesting
- Random thresholds up to some degree e.g. 100
- Random number of participants
- Test independent for correct error when participants less than threshold
- Random tweaks – 0..=2 of them