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

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.

This PR includes changes from https://github.com/KZen-networks/multisig-schnorr/pull/8 with in addition a rebase from master and removal of compiler warnings.

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?

• Changed every ownership take that was unnecessary with borrowing.

• Changed every unnecessary cloning with ownership take (it's better to let the caller of a function decide if he still needs the variable and should clone or not and just give ownership).

• Replaced every &Vec<T> with &[T], This way even if the caller doesn't have a vector he can still pass it to the function and if he does have a vector he can just use [..]

• Formatted some parts to be more rust idiomatic

Support of new types and trait implementations to make wrapper implementations more straight forward. Wrapper implementations take this repo and wrap it with the needed multi-party communication. Changes specifically refer to Zilliqa Schnorr.

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

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.

This PR fixes issue #35

The sha256 hash function which is used in schnorr signature generation receives inputs as BigInt value. But the BigInt value eliminate head bytes if it is zero. So that, the output of hash function was wrong. This commit changes the message into BigInt array for each byte of the message.

It also include changing zilliqa part. But i don't know much about zilliqa, so I wonder if it is ok.🤔

P.S.

BIP-340 computes e from x coordinate of R and P at present. I think that this change should be applied to not only message but also R and P when updating this library to latest bitcoin schnorr specification.

I'm wondering if there are something i don't know... but I thought current create_hash signature such as receiving reference of BigInt slice is not good so much because it leads kind of this issue.

Thank you for your support 😄 @omershlo .

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.

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