Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WIP] Draft ZIP: Multisig #221

Closed
wants to merge 10 commits into from

Conversation

@omershlo
Copy link

omershlo commented Mar 31, 2019

This is preamble + abstract + motivation of zip-multisig.

@daira

This comment has been minimized.

Copy link
Collaborator

daira commented Apr 2, 2019

Hi, can you give a brief outline of what the protocol is, please? (Either here or on zcash/zcash#782 .)

========

`SpendAuthSig` is a Schnorr based signature used in Sapling to sign transactions.
In this ZIP We describe an efficient protocol for threshold signing. The protocol can be used

This comment has been minimized.

Copy link
@rex4539

This comment has been minimized.

Copy link
@omershlo

omershlo Apr 2, 2019

Author

thanks for the catch, fixed it!

@omershlo

This comment has been minimized.

Copy link
Author

omershlo commented Apr 2, 2019

@daira I added a Specification section with somewhat abstracted description of 2p-multisig.

@rex4539
rex4539 approved these changes Apr 3, 2019
@omershlo

This comment has been minimized.

Copy link
Author

omershlo commented Apr 19, 2019

We started to write some reference code for review: https://github.com/KZen-networks/paradise-city

@acityinohio

This comment has been minimized.

Copy link
Collaborator

acityinohio commented Apr 30, 2019

@omershlo would you be able to add the level of detail in the paper here to this ZIP for comment?

@omershlo

This comment has been minimized.

Copy link
Author

omershlo commented Apr 30, 2019

@acityinohio sure. It will be added in the next few days.

@omershlo

This comment has been minimized.

Copy link
Author

omershlo commented May 1, 2019

@acityinohio I added a detailed spec for the two party case. The details spec is following the lines of the reference implementation more than the current version of the paper (to be updated accordingly in a few days).

@omershlo

This comment has been minimized.

Copy link
Author

omershlo commented May 1, 2019

A short discussion I had with @daira over the community chat. Following this discussion we decided to implement r_i as choose random number instead of r=H(T|||vk||M).

My question:
in RedDSA you define r=H(T|||vk||M), can you explain the motivation behind this choice?
in ed25519 r is chosen to be hash of the message (and some constant randomness ) to make it so that no signature will be the same for different messages and still no need for random generator. In RedDSA why you are pushing T and vk ? what attack would be possible if I just do r = H(a || M) ? for some random a chosen once?
In fact, looking at the implementation for single party of RedJubjub: https://github.com/zcash/librustzcash/blob/master/sapling-crypto/src/redjubjub.rs#L87 it seems that they don't consider vk inside the hash

Answer:
the security requirement is that r be uniform-random per signature. The generation of r in EdDSA/Ed25519 can be modelled as applying a PRF to the message with a key derived from the private key. In RedDSA however, we need to be able to rerandomize the private key homomorphically. That precludes generating the private key from a seed as EdDSA does.

How, then, should we preserve the spirit of the EdDSA design? When rerandomizing a private key we could keep the same seed for the PRF used to generate r, but that would be a mistake, because we would be changing the key but using the same PRF instance, possibly leading to reuse of r across signatures for different keys. Instead, we just drop the idea of generating r deterministically. This option is simpler and has no significant security downside, since we're already relying on a good RNG to randomize keys. However, we still want to reduce the possibility of implementation mistakes that could result in using a nonuniform r. That is the main reason why the spec defines a way of generating r that requires T to have sufficient entropy, but does not require T to be uniform.
For the second issue you raise, see #190 and zcash-hackworks/sapling-crypto#77

zip-multisig.rst Show resolved Hide resolved
zip-multisig.rst Outdated Show resolved Hide resolved
zip-multisig.rst Outdated Show resolved Hide resolved
zip-multisig.rst Outdated Show resolved Hide resolved
zip-multisig.rst Outdated Show resolved Hide resolved
zip-multisig.rst Outdated Show resolved Hide resolved

Specification
==========
We start by describing the two party case, followed by an extension to any number of parties and any threshold. We refer to the [paper](https://github.com/KZen-networks/paradise-city/tree/master/paper%5Bwip%5D) for the security proof of the schemes

This comment has been minimized.

Copy link
@str4d

str4d May 16, 2019

Contributor

The "extension to any number of parties and any threshold" has not yet been described.

Here is a detailed description of the protocol as it is currently implemented in [paradise-city](https://github.com/KZen-networks/paradise-city):

**2p-KeyGen**
1) `P_1` chooses random scalar `ask_1`, plays the prover in a non-interactive (using Fiat Shamir) sigma protocol for proof of knowledge of discrete log ([proof and ref](https://github.com/KZen-networks/curv/blob/master/src/cryptographic_primitives/proofs/sigma_dlog.rs)). Finally `P_1` commits to the public key `ak_1` and to the proof of knowledge. `P_1` sends the commitment as first message to party `P_2`. We use hash based commitment

This comment has been minimized.

Copy link
@str4d

str4d May 16, 2019

Contributor

The sigma protocol, commitment schemes, and message formats need to be specified as part of the ZIP, given that it will require interaction between multiple parties that might not be using the same implementation.


**2p-Signing**
Given a message `m` and the outputs of 2P-KeyGen the parties run the following protocol to get a signature:
1) `P_1` choose a random seed and sends a Pederson commitment of it to `P_2`. This message initiates a coin flip protocol for many coins with optimal rounds ([ref](https://github.com/KZen-networks/curv/blob/master/src/cryptographic_primitives/twoparty/coin_flip_optimal_rounds.rs)).

This comment has been minimized.

Copy link
@str4d

str4d May 16, 2019

Contributor

The coin flip protocol needs to be specified as part of the ZIP, for the same reason as above.

2) `P_2` verifies the proof, if true, chooses a random seed and sends it to `P_1`.
3) `P_1` computes the result `alpha` as the xor of the two seeds. `P_1` sends a decommitment and a proof of correct use of blinding factor. `P_1` computes `vk = ak + alpha * G`
4) `P_2` verifies the proof and computes `alpha`. `P_2` computes `vk = ak + alpha * G`
5) Since we want concurrent signing (see discussion in section 4.3 of [paper](https://eprint.iacr.org/2017/552.pdf)) we repeat 2p-KeyGen steps 1-4 with the difference that instead of PoK of DLog we prove knowledge that a tuple is a DDH tuple ([proof and ref](https://github.com/KZen-networks/curv/blob/master/src/cryptographic_primitives/proofs/sigma_ec_ddh.rs)). At the end of this phase `P_1` has secret `r_1`, `P_1` has secret `r_2` and both know `R = R_1 + R_2`.

This comment has been minimized.

Copy link
@str4d

str4d May 16, 2019

Contributor

The precise changes to the KeyGen protocol need to be specified as part of the ZIP, as well as the corresponding new message formats.

omershlo and others added 7 commits May 16, 2019
Co-Authored-By: str4d <thestr4d@gmail.com>
Co-Authored-By: str4d <thestr4d@gmail.com>
Co-Authored-By: str4d <thestr4d@gmail.com>
Co-Authored-By: str4d <thestr4d@gmail.com>
Co-Authored-By: str4d <thestr4d@gmail.com>
Co-Authored-By: str4d <thestr4d@gmail.com>
Co-Authored-By: str4d <thestr4d@gmail.com>
@mms710

This comment has been minimized.

Copy link

mms710 commented May 17, 2019

@zmanian Would you be willing to review and provide comments on this ZIP next week?

@mms710

This comment has been minimized.

Copy link

mms710 commented May 20, 2019

@warner Would you be willing to review and provide comments on this ZIP sometime this week?

@mms710

This comment has been minimized.

Copy link

mms710 commented May 22, 2019

Hi @zmanian and @warner, just checking back in. Would you be willing to review and provide comments on this ZIP by the end of this week?

@zebambam zebambam self-requested a review May 23, 2019
@mms710

This comment has been minimized.

Copy link

mms710 commented May 24, 2019

Hi @zmanian and @warner! Just a reminder that we'd like your reviews of these ZIPs today if possible. Thanks!

@zmanian

This comment has been minimized.

Copy link

zmanian commented May 26, 2019

From the point of consensus, any of a number of known aggregate signing schemes can be used and appear the same on chain.

These schemes tend to differ in how they protect against attacks by the signers against each other. I haven't reviewed this scheme cryptographically but because it doesn't require any protocol upgrades it could be accepted by the Zcash community as one of the acceptable protocols for the 2 party aggregate case that wallets might implement.

@zookozcash

This comment has been minimized.

Copy link

zookozcash commented May 31, 2019

For the record, I've read this ZIP and all of the comments up to here.

@daira daira force-pushed the zcash:master branch 15 times, most recently from 4864dde to c333fe2 Aug 6, 2019
@daira daira force-pushed the zcash:master branch from 0aef8ce to 2815bee Aug 24, 2019
@daira daira added the ZIP idea label Sep 3, 2019
@omershlo omershlo closed this Nov 11, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
8 participants
You can’t perform that action at this time.