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

[Schnorr API BREAK] Improve Schnorr multisigning API + fix vulnerability #322

Closed
wants to merge 2 commits into from

Conversation

sipa
Copy link
Contributor

@sipa sipa commented Sep 28, 2015

This reworks the Schnorr multisigning API to 4 self-contained functions:

  • secp256k1_multischnorr_stage1 computes public nonces
  • secp256k1_multischnorr_stage2 computes partial signatures using those public nonces
  • secp256k1_multischnorr_combine_sigs combines stage2 sigs into a full signature
  • secp256k1_multischnorr_combine_keys combines signers' public keys into a combined public key.

This changes the combined public key to be A*H(A) + B*H(B) + C*H(C) + ..., in an attempt to prevent a pubkey cancellation vulnerability.

The documentation is also moved out to a separate schnorr.md document.

@sipa
Copy link
Contributor Author

sipa commented Nov 1, 2015

Rebased, and added several guarantee-zeroed-output cases. Ping @gmaxwell

* by calling the function again (they are commutative and associative).
* All cosigners must use the same msg32, and the same as in stage1. You must
* also use the same noncefp/ndata for your own stage1 and stage2. Other
* participants may use different nonce generation, though.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you should be more explicit: "Different participants may use different nonce generating functions and data, as long as they are each consistent between stage 1 and stage 2."

Up to you.

Edit Oh, you say this in the first sentence. So I think replace "You" with "Each participant" and "Other" with "Different" then.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed. Used your language.

@sipa
Copy link
Contributor Author

sipa commented Dec 12, 2015

Addressed nits.

@apoelstra
Copy link
Contributor

Hi, sorry for the delays, this fell off my radar. Will review today while in flight.

@sipa
Copy link
Contributor Author

sipa commented Feb 16, 2016

@apoelstra Subtle ping

@fanatid
Copy link
Contributor

fanatid commented Apr 20, 2016

@sipa can you explain Verification (method 1)?

x - private key, k - private nonce
m - 32 byte message, Q - public key, signature pair - (R.x, s)

signing:
R = G^k
e = SHA256(R.x || m)
s = k - e * x
signature is (R.x, s)

verify:
e = SHA256(R.x || m)
R' = Q^e + G^s = G^(x * e) + G^(k - e * x) = ???

How G^(x * e) + G^(k - e * x) can be equal to R = G^k?
if instead + will be * all be ok:

R' = G^(x * e) * G^(k - e * x) = G^(x * e + k - e * x) = G^k

@sipa
Copy link
Contributor Author

sipa commented Apr 20, 2016

@fanatid I think you're confusing additive notation with multiplicative notation.

We call the EC group operation +, and its repeated application a number of times *, so when a + b = c, then c*G = (a+b)*G = a*G + b*G

@fanatid
Copy link
Contributor

fanatid commented Apr 20, 2016

@sipa thank you! I really forgot that EC multiplication is repeated addition.

* Check whether all `R_all(j).x` values in each of the stage 2 signature are
identical. If not, fail.
* Compute the sum `s_all` of all `s(j)` values.
* The full combined signature is `(R_all.x, s(i))`.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(R_all.x, s_all) ?

@sipa
Copy link
Contributor Author

sipa commented Jun 29, 2016

Going to do this differently.

@sipa sipa closed this Jun 29, 2016
@prusnak
Copy link

prusnak commented Mar 23, 2017

Going to do this differently.

Is there a source where I can learn how this is being done today?

Also not sure if helpful, but I found a working two-stage cosigning implementation for ed25519 in Go:

@sipa
Copy link
Contributor Author

sipa commented Mar 23, 2017

@prusnak In review we discovered the AH(A) + BH(B) + ... scheme was vulnerable to a generalized birthday attack. We have a new scheme, but no strong proof for security yet. I didn't know about CoSi - I'll have a look at it.

@businessintegrator
Copy link

What about collision period of the H function?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants