zengo-x / multi-party-schnorr

Rust implementation of multi-party Schnorr signatures over elliptic curves.

Multi Party Schnorr Signatures

This library contains several Rust implementations of multi-signature Schnorr schemes. Generally speaking, these schemes can be classified into:

1. {n,n}-multi-signature scheme. These schemes require that all parties engage in cooperation to issue the signature.
2. {t,n}-threshold-signature schemes (TSS). These schemes require that any subset of at least t+1 parties engage in cooperation to issue a valid signature.

Different protocol implementation

This repo implements different Schnorr multi-signature schemes. There is tradoffs between these schemes with respect to type, performance, communications rounds and security assumptions. We use abbreviations DLP, ROM, ASM for respectively, discrete log problem, random oracle model, algebraic group model.

protocol	Type	Rounds	Assumptions	comments
Boneh, et al.(MuSig) [2] (section 5)	{n,n}	3	DLP, ROM	fixes the security proof of [1]
Nick, et al.(MuSig2) [3]	{n,n}	2	DLP, ROM, AGM	improvement on [2]
Micali, et al. [4]	{n,n}	3	DLP, ROM
Stinson-Strobl [5]	{t,n}	3	DLP, ROM	See (*)

(*) For more efficient implementation we used the DKG from Fast Multiparty Threshold ECDSA with Fast Trustless Setup. The cost is robustness: if there is a malicious party out of the n parties in DKG the protocol stops and if there is a malicious party out of the t parties used for signing the signature protocol will stop

Disclaimers:

(1) This code should not be used for production at the moment.

(2) This code is not secure against side-channel attacks

(3) The code does not contain a network layer (if you are interested, check white-city for ongoing effort, contribtutions are welcome)

Contact

Feel free to reach out or join the ZenGo X Telegram for discussions on code and research.

License

The library is released under the terms of the GPL-3.0 license. See LICENSE for more information.

References

[1] https://github.com/KZen-networks/multi-party-schnorr/blob/master/papers/simple_schnorr_multi_signatures_with_applications_to_bitcoin.pdf

[2] https://github.com/KZen-networks/multi-party-schnorr/blob/master/papers/compact_multi_signatures_for_smaller_blockchains.pdf

[3] https://github.com/KZen-networks/multi-party-schnorr/blob/master/papers/musig2_simple_two_round_schnorr_multi_signatures.pdf

[4] https://github.com/KZen-networks/multi-party-schnorr/blob/master/papers/accountable_subgroups_multisignatures.pdf

[5] https://github.com/KZen-networks/multi-party-schnorr/blob/master/papers/provably_secure_distributed_schnorr_signatures_and_a_threshold_scheme.pdf

multi-party-schnorr's Issues

Test Jacobi of R

see: https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki
in sign:

if jacobi(R[1]) != 1:
      k = n - k

in verify:

    if R is None or jacobi(R[1]) != 1 or R[0] != r:
        return False

Compare to Schnorrkel

https://github.com/w3f/schnorrkel is based on ristretto curve and implements MuSig. multi-party-schnorr can also use Ristretto and MuSig is implemented. It will be interesting to compare both implementations.

cc: @burdges

Add support for threshold schnorr

based on the paper: https://github.com/KZen-networks/multi-party-schnorr/blob/master/papers/provably_secure_distributed_schnorr_signatures_and_a_threshold_scheme.pdf
The keygen from http://stevengoldfeder.com/papers/GG18.pdf can be used : https://github.com/KZen-networks/multi-party-ecdsa/tree/pdl-sub-protocol/src/protocols/multi_party_ecdsa/gg_2018

Fix a small typo in protocol PDF

Public parameters should be (\Group, q, \Generator) (instead of (\Group, g, \Generator)).

what is the EphemeralKey?

I'm still learning about MuSig so sorry if this is obvious but I'm wondering what the Ephemeral Key is and if its part of the MuSig spec or an implementation detail. Also, what is the difference in using EphemeralKey::create_from_private_key over EphemeralKey::create, is there any reason to use one over the other?

Architecture change to support {n,n} MuSig

currently the code is designed for 2 parties. Find a new design to support any number of signers.

add bitcoin support

follow the guidelines in Schnorr BIP: https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki
The cryptographic protocol is the same therefore most of the work is for:

1. add the test vectors from the BIP and verify correctness
2. translate to the BIP encodings of the different elements

separate code of bip-schnorr sigs from Aggsig

thanks to the awesome Jonas Nick!

add test for 3 out of 3 aggregate signature

Wagner's k-sum attack

If I understand, your code implements two round Schnorr multi-signature, much as https://github.com/KZen-networks/multi-party-schnorr/blob/master/papers/accountable_subgroups_multisignatures.pdf describes.

There is a somewhat viable forgery attack against all known two round Schnorr threshold/multi/etc. signatures given in https://eprint.iacr.org/2018/417.pdf that works by doing a roughly 2^40 computation while holding open 127 parallel signing queries.

We've an approach for a fix, but so far failed to prove security. We're still recommending the three round trip version as implemented in https://github.com/w3f/schnorrkel/blob/master/src/musig.rs but maybe that'll change in 2020 if we fix our fix. ;)

As an aside, you should manage MPCs with session types that encode the protocol's security requirements when using Rust, because even highly skilled developers routinely miss-use MPC libraries. These session types cannot be cloned, copied, serialized, etc. and can only be either dropped or consumed by value when advancing the state machine, like in https://github.com/w3f/schnorrkel/blob/master/src/musig.rs#L403

Schnorr Blind Signature support?

Is there any support or planned support of Schnorr Blind Signatures?

add simple schnorr protocol test

at the moment test.rs contains only {2,2} test. It is feasible to expand party1 interface to generate simple schnorr signature

transform doc to wiki

Add Wiki for MIcali Multisig protocol

Implemented here: https://github.com/KZen-networks/multi-party-schnorr/tree/master/src/protocols/multisig

Possibility of using with zilliqa-js-sdk?

Hello,

I want to demonstrate TSS for Zilliqa and not sure about how plausible it is. I understand that it is now possible to compile Rust to webassembly and then it could be used in the same environments as the zilliqa-javascript-sdk. Is this presently practical to attempt or request? I am experienced with c/c++ but not rust or webassembly. How will developers use the TSS scheme with Zilliqa as it stands? There is no Rust sdk.

Add support to bip340

https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki

unit-testing

Wrong local sig is generated, when the first byte of a hash input is 0.

Current LocalSig generation code in src/protocols/thresholdsig/bitcoin_schnorr.rs uses a hash function which get input values as BigInt. However, if the first bytes of input is 0, the BigInt omit the 0. So the final hash value is going to be wrong.

I tried to create signature with this crate and i got some wrong signatures. It couldn't be verified on other schnorr signature verification code like this.

This is a simple test case for the hash function. The assertion is failure.

extern crate curv;
extern crate sha2;
extern crate hex;

#[test]
fn test_hash() {
    let message: Vec<u8> = vec![0, 1];

    let target = {
        use curv::cryptographic_primitives::hashing::hash_sha256::HSha256;
        use curv::cryptographic_primitives::hashing::traits::Hash;
        use curv::BigInt;
        use curv::arithmetic::traits::Converter;

        let big_int = BigInt::from(&message[..]);
        HSha256::create_hash(&[&big_int]).to_hex()
    };

    let expected = {
        use sha2::Sha256;
        use sha2::Digest;

        let mut hasher = Sha256::new();
        hasher.input(&message);
        hex::encode(hasher.result())
    };

    assert_eq!(target, expected);
}

I think that the signature compute code should use other hash function implementation or fix it.

update readme file

please update the readme file to :

1. provide references https://eprint.iacr.org/2018/068.pdf and https://eprint.iacr.org/2018/483.pdf
2. add disclaimer that this code should not be used in production for now
3. add disclaimer that this code is not secure under non-cryptographic attacks. i.e. side channels

Second round is unnecessary

If, in the first round each party uses a proof of knowledge of secret key, the second round where signers verify the commitment - which is necessary to prevent a rogue key attack - is not needed. In addition, there's no need to use each of the signer's public keys in the hash.

Instead a precomputed aggregate public key can be used for a given set of signers and a given threshold. Since proof of secret key was used during the establishment of this aggregate, it cannot be pre-selected, and is sufficient to use in the subsequent digest computations.

Finally, it is often desirable for signature schemes to be "malleable" (each message gets a unique sig), and others to be "fixed", (the signature corresponding to a given message is deterministic).

Such a library should allow for both scenarios.

Separate structs in Multisig protocol to public ones and local ones

Following the same paradigm as in https://github.com/KZen-networks/curv/blob/master/src/cryptographic_primitives/twoparty/dh_key_exchange.rs

Check validity of a partial signature?

Hello, I was reading the tests for aggregate signatures and I noticed there didn't seem to be any asserts to check the validity of partial signatures. Is this an easy feature to add to the library?

Add Travis CI

Add Travis CI and badge