eeca440fa7
This converts proofs from 2n elements to 1+n. Moves FROST over to it. Additionally, for FROST's binomial nonces, provides a single DLEq proof (2, not 1+2 elements) by proving the discrete log equality of their aggregate (with an appropriate binding factor). This may be split back up depending on later commentary...
3.3 KiB
FROST
Serai implements FROST, as specified in draft-irtf-cfrg-frost-11.
Modularity
In order to support other algorithms which decompose to Schnorr, our FROST
implementation is generic, able to run any algorithm satisfying its Algorithm
trait. With these algorithms, there's frequently a requirement for further
transcripting than what FROST expects. Accordingly, the transcript format is
also modular so formats which aren't naive like the IETF's can be used.
Extensions
In order to support algorithms which require their nonces be represented across
multiple generators, FROST supports providing a nonce's commitments across
multiple generators. In order to ensure their correctness, an extended
CP93's Discrete Log Equality Proof
is used. The extension is simply to transcript n generators, instead of just
two, enabling proving for all of them at once.
Since FROST nonces are binomial, every nonce would require two DLEq proofs. To
make this more efficient, we hash their commitments to obtain a binding factor,
before doing a single DLEq proof for d + be, similar to how FROST calculates
its nonces (as well as MuSig's key aggregation).
As some algorithms require multiple nonces, effectively including multiple Schnorr signatures within one signature, the library also supports providing multiple nonces. The second component of a FROST nonce is intended to be multiplied by a per-participant binding factor to ensure the security of FROST. When additional nonces are used, this is actually a per-nonce per-participant binding factor.
When multiple nonces are used, with multiple generators, we use a single DLEq
proof for all nonces, merging their challenges. This provides a proof of 1 + n
elements instead of 2n.
Finally, to support additive offset signing schemes (accounts, stealth
addresses, randomization), it's possible to specify a scalar offset for keys.
The public key signed for is also offset by this value. During the signing
process, the offset is explicitly transcripted. Then, the offset is divided by
p, the amount of participating signers, and each signer adds it to their
post-interpolation key share. This maintains a leaderless protocol while still
being correct.
Caching
modular-frost supports caching a preprocess. This is done by having all preprocesses use a seeded RNG. Accordingly, the entire preprocess can be derived from the RNG seed, making the cache just the seed.
Reusing preprocesses would enable a third-party to recover your private key share. Accordingly, you MUST not reuse preprocesses. Third-party knowledge of your preprocess would also enable their recovery of your private key share. Accordingly, you MUST treat cached preprocesses with the same security as your private key share.
Since a reused seed will lead to a reused preprocess, seeded RNGs are generally frowned upon when doing multisignature operations. This isn't an issue as each new preprocess obtains a fresh seed from the specified RNG. Assuming the provided RNG isn't generating the same seed multiple times, the only way for this seeded RNG to fail is if a preprocess is loaded multiple times, which was already a failure point.