path: root/a5/7e88843abdd5a483c0ec6e87800a9e2a9c6454

Return-Path: <tom@commerceblock.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 35807C0032
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 24 Jul 2023 15:57:57 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 0A6D461042
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 24 Jul 2023 15:57:57 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 0A6D461042
Authentication-Results: smtp3.osuosl.org;
 dkim=pass (2048-bit key) header.d=commerceblock-com.20221208.gappssmtp.com
 header.i=@commerceblock-com.20221208.gappssmtp.com header.a=rsa-sha256
 header.s=20221208 header.b=3loRGGck
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id t_4pHuP4mfgv
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 24 Jul 2023 15:57:55 +0000 (UTC)
Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com
 [IPv6:2a00:1450:4864:20::636])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 1477960F82
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 24 Jul 2023 15:57:54 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 1477960F82
Received: by mail-ej1-x636.google.com with SMTP id
 a640c23a62f3a-99364ae9596so793501566b.1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 24 Jul 2023 08:57:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=commerceblock-com.20221208.gappssmtp.com; s=20221208; t=1690214273;
 x=1690819073; 
 h=to:subject:message-id:date:from:in-reply-to:references:mime-version
 :from:to:cc:subject:date:message-id:reply-to;
 bh=jxDR5cJJuLOmUUnVUS/TE7b98h08ngyJMFFb89BAx1U=;
 b=3loRGGckwVj00oiQ207s6PkaM5LfjC2J/mF+YKtSAVj+MpBgp6npmDVyE+u7Rod1Z8
 96WnKuFypWHr4OdHej0Dy/hwtW1MNXh1rIYVIRaQ1nopxofPTl47RmoMsXrrco4AKvGi
 uGT/wdAiHyvVWd7ejmwBAsuSNTqwIqE7yyRCzxUeh5E46UxX0vxzgi4AWfsPMZolC2Tt
 UBjh0g7DU1l7IUZE9NwqH7V9n7cU4+EB6D8cax2yWgg9zCHyJVsSnSDrfqwrV1JDE4Cl
 ZqA4WWH+uGWXAg6gB6itUi2lDio7oKTKA4jJAMH9nBOqyW/83kRfdqol/2ajekb9WBMB
 oRqg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20221208; t=1690214273; x=1690819073;
 h=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=jxDR5cJJuLOmUUnVUS/TE7b98h08ngyJMFFb89BAx1U=;
 b=K0GWpyv8Fo7CTSDS+2666vH6lHUuDw3mBA5ueXfd1hXZDLo48os4gXPgd48gkRqOZU
 /g9AEH+Rze4+Lj/byEZf2oFLAk458aMaojjGUn+VWFifA+k6eC7Jj7GyD3zKlVDD9zx8
 znaMdRlykufQNET3oZIPQgKPyzrvsiWs3/jfdyMRXLCY0yJVqFTy6JIwoS7WKA8HInSs
 2te1A6NjwOReRX6JG8eJI2X0buoLwZxSSqTU2RvknjFA9z5VsqRilg4qomtwDvY5JJzr
 XFrfgJlgJLTAOfk9OJNaT5wkYd5fhrNhtYTKipg9ka63mOVnLwrmMxtoWoBYbD0YpZvM
 bmTw==
X-Gm-Message-State: ABy/qLYqmdCga0FENp86y/yKj49c2lV0238aNNdLqFwUo+Xj7s2yFPN8
 hEpW+w7ouObRTNgnGgRYEuPQd20WCBMpeE01Fx7+sDQiMjU9Ewk7BQ==
X-Google-Smtp-Source: APBJJlEN8+hFinneYJzMsGyg8ou+ikjvVpCFAgRUUJhJKvuBW6Tqx4sEntduQz0+QVG+ESzx+cDtUE+wQPig3Cf9Ubs=
X-Received: by 2002:a17:906:59:b0:993:f744:d235 with SMTP id
 25-20020a170906005900b00993f744d235mr11523918ejg.6.1690214272715; Mon, 24 Jul
 2023 08:57:52 -0700 (PDT)
MIME-Version: 1.0
References: <CAJvkSsc_rKneeVrLkTqXJDKcr+VQNBHVJyXVe=7PkkTZ+SruFQ@mail.gmail.com>
 <4kTcpBuEgsQQDiKbxOQwJ9ZCuHvWXGotb8eWGESe2wJs5e-6ke7435NyGmNfBRP17w7UoXR4c59v_6uQWRonHfvv_n545WPgt68a0cBQi-k=@protonmail.com>
In-Reply-To: <4kTcpBuEgsQQDiKbxOQwJ9ZCuHvWXGotb8eWGESe2wJs5e-6ke7435NyGmNfBRP17w7UoXR4c59v_6uQWRonHfvv_n545WPgt68a0cBQi-k=@protonmail.com>
From: Tom Trevethan <tom@commerceblock.com>
Date: Mon, 24 Jul 2023 16:57:41 +0100
Message-ID: <CAJvkSsdStaiFOTCXRvPegGoQ9_VqsR7JmsKoSwx2_DnrCxvBrg@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000051e01c06013dad6b"
X-Mailman-Approved-At: Mon, 24 Jul 2023 16:37:34 +0000
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Jul 2023 15:57:57 -0000

--00000000000051e01c06013dad6b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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=E2=80=AFAM ZmnSCPxj <ZmnSCPxj@protonmail.com>=
 wrote:

> 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
> 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 tha=
t
> 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 tha=
t
> 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 signature=
s
> 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 s=
et
> of signatures generated being verified client side
> https://github.com/commerceblock/mercury/blob/master/doc/merc_blind.md#bl=
inding-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 generat=
or
> point 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
> generates 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). T=
he
> shared (aggregate) public key X =3D a1X1 + a2X2 where a1 =3D KeyAggCoef(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 final
> signature seems straightforward, if party 1 doesn't not need to
> independently compute and verify c =3D H(X||R||m) (as they are blinded fr=
om
> 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 R=
1
> to party 2.
> > 3) Party 2 computes c =3D H(X||R||m) and sends it to party 1 in order t=
o
> 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
>

--00000000000051e01c06013dad6b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi ZmnSCPxj,<br><br>Yes, you are correct - the full scheme=
 (<a href=3D"https://eprint.iacr.org/2020/1261.pdf">https://eprint.iacr.org=
/2020/1261.pdf</a>) should have two or more nonces (and also compute b). I =
don&#39;t think this changes the approach to blinding however.=C2=A0<br></d=
iv><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On =
Mon, Jul 24, 2023 at 11:50=E2=80=AFAM ZmnSCPxj &lt;<a href=3D"mailto:ZmnSCP=
xj@protonmail.com">ZmnSCPxj@protonmail.com</a>&gt; wrote:<br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px=
 solid rgb(204,204,204);padding-left:1ex">Good morning Tom,<br>
<br>
Would this allow party 2 to itself be composed of N &gt;=3D 2 parties?<br>
<br>
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.<br>
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.<br>
(it is the reason why MuSig1 requires 3 round trips, and why MuSig2 require=
s at least 2 `R` nonces per signatory)<br>
<br>
Your scheme has only one `R` per party, would it not be vulnerably to that =
attack?<br>
<br>
Regards,<br>
ZmnSCPxj<br>
<br>
<br>
Sent with Proton Mail secure email.<br>
<br>
------- Original Message -------<br>
On Monday, July 24th, 2023 at 7:46 AM, Tom Trevethan via bitcoin-dev &lt;<a=
 href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bi=
tcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
<br>
<br>
&gt; 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 &#39;blinded&#39; -=
 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.<br>
&gt; <br>
&gt; 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 <a href=3D"https://github.com/comme=
rceblock/mercury/blob/master/doc/merc_blind.md#blinding-considerations" rel=
=3D"noreferrer" target=3D"_blank">https://github.com/commerceblock/mercury/=
blob/master/doc/merc_blind.md#blinding-considerations</a><br>
&gt; <br>
&gt; 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):<br>
&gt; <br>
&gt; 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).<br>
&gt; <br>
&gt; 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.<br>
&gt; <br>
&gt; Party 1 then computes &#39;challenge&#39; c =3D H(X||R||m) and s1 =3D =
c.a1.x1 + r1<br>
&gt; Party 2 then computes &#39;challenge&#39; c =3D H(X||R||m) and s2 =3D =
c.a2.x2 + r2<br>
&gt; <br>
&gt; The final signature is then (R,s1+s2).<br>
&gt; <br>
&gt; In the case of blinding this for party 1:<br>
&gt; <br>
&gt; To prevent party 1 from learning of either the full public key or fina=
l signature seems straightforward, if party 1 doesn&#39;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).<br>
&gt; <br>
&gt; 1) Key aggregation is performed only by party 2. Party 1 just sends X1=
 to party 2.<br>
&gt; 2) Nonce aggregation is performed only by party 2. Party 1 just sends =
R1 to party 2.<br>
&gt; 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<br>
&gt; <br>
&gt; Party 1 never learns the final value of (R,s1+s2) or m.<br>
&gt; <br>
&gt; Any comments on this or potential issues would be appreciated.<br>
&gt; <br>
&gt; Tom<br>
</blockquote></div>

--00000000000051e01c06013dad6b--