{"type":"rich","version":"1.0","title":"ZmnSCPxj [ARCHIVE] wrote","author_name":"ZmnSCPxj [ARCHIVE] (npub1g5…3ms3l)","author_url":"https://yabu.me/npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3l","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2023-07-24\n🗒️ Summary of this message: MuSig2 requires multiple `R` points, preventing certain attacks. The recipient questions if the scheme's single `R` per party is vulnerable.\n📝 Original message:\nGood morning Tom,\n\nWould this allow party 2 to itself be composed of N \u003e= 2 parties?\n\nMuSig2 (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.\nThis 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.\n(it is the reason why MuSig1 requires 3 round trips, and why MuSig2 requires at least 2 `R` nonces per signatory)\n\nYour scheme has only one `R` per party, would it not be vulnerably to that attack?\n\nRegards,\nZmnSCPxj\n\n\nSent with Proton Mail secure email.\n\n------- Original Message -------\nOn Monday, July 24th, 2023 at 7:46 AM, Tom Trevethan via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\n\u003e 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.\n\u003e \n\u003e 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\n\u003e \n\u003e 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):\n\u003e \n\u003e 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).\n\u003e \n\u003e 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.\n\u003e \n\u003e Party 1 then computes 'challenge' c = H(X||R||m) and s1 = c.a1.x1 + r1\n\u003e Party 2 then computes 'challenge' c = H(X||R||m) and s2 = c.a2.x2 + r2\n\u003e \n\u003e The final signature is then (R,s1+s2).\n\u003e \n\u003e In the case of blinding this for party 1:\n\u003e \n\u003e 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).\n\u003e \n\u003e 1) Key aggregation is performed only by party 2. Party 1 just sends X1 to party 2.\n\u003e 2) Nonce aggregation is performed only by party 2. Party 1 just sends R1 to party 2.\n\u003e 3) Party 2 computes c = H(X||R||m) and sends it to party 1 in order to compute s1 = c.a1.x1 + r1\n\u003e \n\u003e Party 1 never learns the final value of (R,s1+s2) or m.\n\u003e \n\u003e Any comments on this or potential issues would be appreciated.\n\u003e \n\u003e Tom"}