rich1.0Tom Trevethan [ARCHIVE] (npub1ax…wyw7n)https://yabu.me/npub1axshsyxsl3vasj4z9549rvwdvhjmh52fw0ayj3ghtmdezx8cnuxqlwyw7nnjumphttps://yabu.me📅 Original date posted:2023-07-24 🗒️ Summary of this message: The sender acknowledges that the full scheme should have multiple nonces and compute b, but it doesn't change the approach to blinding. 📝 Original message: Hi ZmnSCPxj, Yes, you are correct - the full scheme ( https://eprint.iacr.org/2020/1261.pdf) should have two or more nonces (and also compute b). I don't think this changes the approach to blinding however. On Mon, Jul 24, 2023 at 11:50 AM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote: > Good morning Tom, > > Would this allow party 2 to itself be composed of N >= 2 parties? > > MuSig2 (as opposed to MuSig1) requires that signatories provide multiple > `R` points, not just one each, which are finally aggregated by first > combining them using the MuSig() public key compose function. > This prevents party 2 from creating an `R` that may allow it to perform > certain attacks whose name escapes me right now but which I used to know. > (it is the reason why MuSig1 requires 3 round trips, and why MuSig2 > requires at least 2 `R` nonces per signatory) > > Your scheme has only one `R` per party, would it not be vulnerably to that > attack? > > Regards, > ZmnSCPxj > > > Sent with Proton Mail secure email. > > ------- Original Message ------- > On Monday, July 24th, 2023 at 7:46 AM, Tom Trevethan via bitcoin-dev < > bitcoin-dev at lists.linuxfoundation.org> wrote: > > > > We are implementing a version of 2-of-2 Schnorr Musig2 for statechains > where the server (party 1 in the 2-of-2) will be fully 'blinded' - in that > it can hold a private key that is required to generate an aggregate > signature on an aggregate public key, but that it does not learn either: 1) > The aggregate public key 2) The aggregate signature and 3) The message (m) > being signed. > > > > In the model of blinded statechains, the security rests on the > statechain server being trusted to report the NUMBER of partial signatures > it has generated for a particular key (as opposed to being trusted to > enforce rules on WHAT it has signed in the unblinded case) and the full set > of signatures generated being verified client side > https://github.com/commerceblock/mercury/blob/master/doc/merc_blind.md#blinding-considerations > > > > Given the 2-of-2 musig2 protocol operates as follows (in the following > description, private keys (field elements) are denoted using lower case > letters, and elliptic curve points as uppercase letters. G is the generator > point and point multiplication denoted as X = xG and point addition as A = > G + G): > > > > Party 1 generates private key x1 and public key X1 = x1G. Party 2 > generates private key x2 and public key X2 = x2G. The set of pubkeys is L = > {X1,X2}. The key aggregation coefficient is KeyAggCoef(L,X) = H(L,X). The > shared (aggregate) public key X = a1X1 + a2X2 where a1 = KeyAggCoef(L,X1) > and a2 = KeyAggCoef(L,X2). > > > > To sign a message m, party 1 generates nonce r1 and R1 = r1G. Party 2 > generates nonce r2 and R2 = r2G. These are aggregated into R = R1 + R2. > > > > Party 1 then computes 'challenge' c = H(X||R||m) and s1 = c.a1.x1 + r1 > > Party 2 then computes 'challenge' c = H(X||R||m) and s2 = c.a2.x2 + r2 > > > > The final signature is then (R,s1+s2). > > > > In the case of blinding this for party 1: > > > > To prevent party 1 from learning of either the full public key or final > signature seems straightforward, if party 1 doesn't not need to > independently compute and verify c = H(X||R||m) (as they are blinded from > the message in any case). > > > > 1) Key aggregation is performed only by party 2. Party 1 just sends X1 > to party 2. > > 2) Nonce aggregation is performed only by party 2. Party 1 just sends R1 > to party 2. > > 3) Party 2 computes c = H(X||R||m) and sends it to party 1 in order to > compute s1 = c.a1.x1 + r1 > > > > Party 1 never learns the final value of (R,s1+s2) or m. > > > > Any comments on this or potential issues would be appreciated. > > > > Tom > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230724/1df56267/attachment-0001.html>