FROST super issue

[LLFourn]

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 gen_nonce 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/collect_polys/new_keygen/
• s/FirstRoundError/NewKeyGenError/
• s/collect_shares/finish_keygen/
• s/SecondRoundError/FinishKeyGenError/

Don’t use HashMap

Doesn’t work with no_std 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

[nickfarrow]

Also:

Self Proving & Validation

Currently user creates and validates their own shares + pop. Is this annoying?

Tweak Tests

Test tweaks thoroughly

There's a secret.clone() when creating the pop

Is there anything special that needs to be done when cloning / consuming secrets for security?

[nickfarrow]

All of these have been implemented in #84 except for additional tweak tests (no test vectors yet)

[LLFourn]

closed by #84. More things to be done but they are not captured by this issue.