frost/secp256k1-zkp
3
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

musig-spec: improve security argument for handling infinity

Browse Source 
Co-authored-by: Tim Ruffing <crypto@timruffing.de>
This commit is contained in:
Elliott Jin 2022-01-26 18:24:39 -08:00
parent 73f0cbd3cc
commit aa1acb4bd1
1 changed files with 15 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

23
doc/musig-spec.mediawiki
View File

@ -129,15 +129,22 @@ The algorithm ''NonceAgg(pubnonce<sub>1..u</sub>)'' is defined as:
===== Note on ''is_infinite(R'<sub>i</sub>)'' ===== ===== Note on ''is_infinite(R'<sub>i</sub>)'' =====
If ''is_infinite(R'<sub>i</sub>)'' there is at least one dishonest signer (except with negligible probability). If ''is_infinite(R'<sub>i</sub>)'' there is at least one dishonest signer (except with negligible probability).
If we would fail here, we will never be able to determine who it is. If we fail here, we will never be able to determine who it is.
Therefore, we should continue such that the culprit is revealed when collecting and verifying partial signatures. Therefore, we continue so that the culprit is revealed when collecting and verifying partial signatures.
However, dealing with the point at infinity requires defining a serialization and may require extra code complexity in implementations.
Instead, we set the aggregate nonce to some arbitrary point, the generator.
This modification does not affect the security of the scheme. However, dealing with the point at infinity requires defining a serialization and may require extra code complexity in implementations.
''NonceAgg'' (both the original and modified version) only depends on publicly available data (the set of public pre-nonces from every signer). Instead of incurring this complexity, we make two modifications (compared to the MuSig2* appendix in the [https://eprint.iacr.org/2020/1261 MuSig2 paper]) to avoid infinity while still allowing us to detect the dishonest signer:
Thus in the multi-signature security game (EUF-CMA), we can consider ''NonceAgg'' to be performed by the adversary (rather than the challenger) without loss of generality. * In ''NonceAgg'', if an output ''R'<sub>i</sub>'' would be infinity, instead output the generator (an arbitrary choice).
The modification changes neither the behavior of the EUF-CMA challenger nor the condition required to win the security game (the adversary still has to output a valid forgery according to the unmodified MuSig2* scheme). Since we've already proved that MuSig2* is secure against an arbitrary adversary, we can conclude that the modified scheme is still secure. * In ''Sign'', implicitly disallow the input ''aggnonce'' to contain infinity (since the serialization format doesn't support it).
The entire ''NonceAgg'' function (both the original and modified version) only depends on publicly available data (the set of public pre-nonces from every signer).
In the unforgeability proof, ''NonceAgg'' is considered to be performed by an untrusted party; thus modifications to ''NonceAgg'' do not affect the unforgeability of the scheme.
The (implicit) modification to ''Sign'' is equivalent to adding a clause, "abort if the input ''aggnonce'' contained infinity".
This modification only depends on the publicly available ''aggnonce''.
Given a successful adversary against the security game (EUF-CMA) for the modified scheme, a reduction can win the security game for the original scheme by simulating the modification (i.e. checking whether to abort) towards the adversary.
We conclude that these two modifications preserve the security of the MuSig2* scheme.
==== Signing ==== ==== Signing ====