From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 9F78FC0032 for ; Mon, 24 Jul 2023 14:25:15 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 655B681D68 for ; Mon, 24 Jul 2023 14:25:15 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 655B681D68 Authentication-Results: smtp1.osuosl.org; dkim=pass (2048-bit key) header.d=q32-com.20221208.gappssmtp.com header.i=@q32-com.20221208.gappssmtp.com header.a=rsa-sha256 header.s=20221208 header.b=mERdnLTH X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mj2ndgrTu6DA for ; Mon, 24 Jul 2023 14:25:14 +0000 (UTC) Received: from mail-yb1-xb2d.google.com (mail-yb1-xb2d.google.com [IPv6:2607:f8b0:4864:20::b2d]) by smtp1.osuosl.org (Postfix) with ESMTPS id 1BE7F81D70 for ; Mon, 24 Jul 2023 14:25:13 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 1BE7F81D70 Received: by mail-yb1-xb2d.google.com with SMTP id 3f1490d57ef6-ca429c9dc0bso471510276.0 for ; Mon, 24 Jul 2023 07:25:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=q32-com.20221208.gappssmtp.com; s=20221208; t=1690208713; x=1690813513; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=PvXOlnK236cc/Hs8Cpo1UHiMheNLtO0BofnhJfl10cQ=; b=mERdnLTHh6RducBjUkdgTkNGf8dKdk34Jn5H4Iwh3+azDfQlAjVlmhtZRciYeL2DwS gqBWgVYNT1ImlvkRWgdE4LW07ciTNhv1zq7Pwnve+1lBs/XoOF425d7cMx4DANicJwuQ mWEWE7MbH+gZddTFVjDlLrDtsBKJyFwdpk33TnsfjFYm40PIjPVqQm5SWs4CtGh53NeB 487mXkVHovQnceAt9RzuNBOJYtNvdheVW/u0CpTOFKYwAzOVAZKOc5B39HXpa4EdFl+L hYkJgjVEVv5OP9XlPs4tyo/HjmexkoX3bITeEj8iCHrGGU2spMH7D7SO+FQ8pG3He/08 7PhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690208713; x=1690813513; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=PvXOlnK236cc/Hs8Cpo1UHiMheNLtO0BofnhJfl10cQ=; b=AxHZWFMiNl4JbMfiuHHUhE4HuNDqkmKjgNxbFwvAB8TtQtvOqhVt+EdIMewEeIg0VC Qi5TcMHSoCFReeX5jydT+ILLYhVG7BLC07eEMRqbeIlCRv7BZ56D476LIpjFdnCDXDFT 4E0M37mlR3uch6moqEPhBmJF3HN1in7zSj0Z+Ff2eOiCXfBv+83mQjpkgqe9mDQryxEt yKVQgTt47s2adbnE+7XPU3xEUWLH7AJ7N7w2LrP58mRRbsUBkiycHTkGfZufkb20dIwH nak4jHd8e7+nxhny45rXzeGHQhIvBB/mbU4HsXrmaP3gkpci6ly+ugAuBSFa0WhZyO5A vUfQ== X-Gm-Message-State: ABy/qLa8OXqNuI0jWUrpRCAX0F3o+rzrI5OCuRVGdb6JDlqVuP38AnMT rgHqbvrqKonwGVfTKvg+J0cTEHk8v8+tg34YijScFYM= X-Google-Smtp-Source: APBJJlHMpz0zyiEDA3Ed7eba2/V9fTDL3KonW+QVDxMsfGV4hIKloHBo9Pw9X6UxG9V15zZrIwbkgrOc28f7NQPwRlE= X-Received: by 2002:a25:db48:0:b0:d0f:6efe:e9dd with SMTP id g69-20020a25db48000000b00d0f6efee9ddmr1432695ybf.0.1690208712674; Mon, 24 Jul 2023 07:25:12 -0700 (PDT) MIME-Version: 1.0 References: <4kTcpBuEgsQQDiKbxOQwJ9ZCuHvWXGotb8eWGESe2wJs5e-6ke7435NyGmNfBRP17w7UoXR4c59v_6uQWRonHfvv_n545WPgt68a0cBQi-k=@protonmail.com> In-Reply-To: <4kTcpBuEgsQQDiKbxOQwJ9ZCuHvWXGotb8eWGESe2wJs5e-6ke7435NyGmNfBRP17w7UoXR4c59v_6uQWRonHfvv_n545WPgt68a0cBQi-k=@protonmail.com> From: Erik Aronesty Date: Mon, 24 Jul 2023 10:25:00 -0400 Message-ID: To: ZmnSCPxj , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000ea5a3106013c6113" X-Mailman-Approved-At: Mon, 24 Jul 2023 14:31:11 +0000 Cc: Tom Trevethan Subject: Re: [bitcoin-dev] Blinded 2-party Musig2 X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2023 14:25:15 -0000 --000000000000ea5a3106013c6113 Content-Type: text/plain; charset="UTF-8" as long as all parties provide a proof of secret key along with their public key, that should not be possible or you can do it as a two-step process where all parties provide a commitment to the public key and nobody reveals a public key until that commitment is received or if you want to be paranoid you can do both On Mon, Jul 24, 2023, 7:00 AM ZmnSCPxj via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> 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@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 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --000000000000ea5a3106013c6113 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
as long as all parties provide a proof of secret key alon= g with their public key, that should not be possible

<= /div>
or you can do it as a two-step process where all par= ties provide a commitment to the public key and nobody reveals a public key= until that commitment is received

or if you want to be paranoid you can do both

On Mon, Jul 2= 4, 2023, 7:00 AM ZmnSCPxj via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> w= rote:
Good morning Tom,

Would this allow party 2 to itself be composed of N >=3D 2 parties?

MuSig2 (as opposed to MuSig1) requires that signatories provide multiple `R= ` points, not just one each, which are finally aggregated by first combinin= g them using the MuSig() public key compose function.
This prevents party 2 from creating an `R` that may allow it to perform cer= tain 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 require= s 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@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 aggregat= e 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 statech= ain server being trusted to report the NUMBER of partial signatures it has = generated for a particular key (as opposed to being trusted to enforce rule= s on WHAT it has signed in the unblinded case) and the full set of signatur= es generated being verified client side https://github.com/commerceblo= ck/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 le= tters, and elliptic curve points as uppercase letters. G is the generator p= oint and point multiplication denoted as X =3D xG and point addition as A = =3D G + G):
>
> Party 1 generates private key x1 and public key X1 =3D x1G. Party 2 ge= nerates private key x2 and public key X2 =3D x2G. The set of pubkeys is L = =3D {X1,X2}. The key aggregation coefficient is KeyAggCoef(L,X) =3D H(L,X).= The shared (aggregate) public key X =3D a1X1 + a2X2 where a1 =3D KeyAggCoe= f(L,X1) and a2 =3D KeyAggCoef(L,X2).
>
> To sign a message m, party 1 generates nonce r1 and R1 =3D r1G. Party = 2 generates nonce r2 and R2 =3D r2G. These are aggregated into R =3D R1 + R= 2.
>
> Party 1 then computes 'challenge' c =3D H(X||R||m) and s1 =3D = c.a1.x1 + r1
> Party 2 then computes 'challenge' c =3D H(X||R||m) and s2 =3D = 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 fina= l signature seems straightforward, if party 1 doesn't not need to indep= endently compute and verify c =3D 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 =3D H(X||R||m) and sends it to party 1 in order = to compute s1 =3D 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
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundati= on.org/mailman/listinfo/bitcoin-dev
--000000000000ea5a3106013c6113--