diff options
| author | Erik Aronesty <erik@q32.com> | 2023-07-24 10:25:00 -0400 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2023-07-24 14:25:15 +0000 |
| commit | 371125794209b4215271dd50d94605c281aef202 (patch) | |
| tree | 9cdac4ac11b3009fa533ebeaa8366a297d77e2fe | |
| parent | 7918783a8525e2ab04fc632e48cb8e21b9f26ee5 (diff) | |
| download | pi-bitcoindev-371125794209b4215271dd50d94605c281aef202.tar.gz pi-bitcoindev-371125794209b4215271dd50d94605c281aef202.zip | |
Re: [bitcoin-dev] Blinded 2-party Musig2
| -rw-r--r-- | fe/5792fdc47020aa43e2966d444818bb8b5ee0d5 | 304 |
1 files changed, 304 insertions, 0 deletions
diff --git a/fe/5792fdc47020aa43e2966d444818bb8b5ee0d5 b/fe/5792fdc47020aa43e2966d444818bb8b5ee0d5 new file mode 100644 index 000000000..25d3e37b6 --- /dev/null +++ b/fe/5792fdc47020aa43e2966d444818bb8b5ee0d5 @@ -0,0 +1,304 @@ +Return-Path: <earonesty@gmail.com> +Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 9F78FC0032 + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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: <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: Erik Aronesty <erik@q32.com> +Date: Mon, 24 Jul 2023 10:25:00 -0400 +Message-ID: <CAJowKg+w+P_+tWbD_Ou7kpPT9j3Xz19mDQqYLd-J5xnM17Argg@mail.gmail.com> +To: ZmnSCPxj <ZmnSCPxj@protonmail.com>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Content-Type: multipart/alternative; boundary="000000000000ea5a3106013c6113" +X-Mailman-Approved-At: Mon, 24 Jul 2023 14:31:11 +0000 +Cc: Tom Trevethan <tom@commerceblock.com> +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 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 + +<div dir=3D"auto">as long as all parties provide a proof of secret key alon= +g with their public key, that should not be possible<div dir=3D"auto"><br><= +/div><div dir=3D"auto">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</div><div dir=3D"auto"><br></div><div di= +r=3D"auto">or if you want to be paranoid you can do both</div></div><br><di= +v class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Jul 2= +4, 2023, 7:00 AM ZmnSCPxj via bitcoin-dev <<a href=3D"mailto:bitcoin-dev= +@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>> w= +rote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex= +;border-left:1px #ccc solid;padding-left:1ex">Good morning Tom,<br> +<br> +Would this allow party 2 to itself be composed of N >=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 <<a= + href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" re= +l=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br> +<br> +<br> +> 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.<br> +> <br> +> 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 noreferrer" target=3D"_blank">https://github.com/commerceblo= +ck/mercury/blob/master/doc/merc_blind.md#blinding-considerations</a><br> +> <br> +> 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> +> <br> +> 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> +> <br> +> 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> +> <br> +> Party 1 then computes 'challenge' c =3D H(X||R||m) and s1 =3D = +c.a1.x1 + r1<br> +> Party 2 then computes 'challenge' c =3D H(X||R||m) and s2 =3D = +c.a2.x2 + r2<br> +> <br> +> The final signature is then (R,s1+s2).<br> +> <br> +> In the case of blinding this for party 1:<br> +> <br> +> 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).<br> +> <br> +> 1) Key aggregation is performed only by party 2. Party 1 just sends X1= + to party 2.<br> +> 2) Nonce aggregation is performed only by party 2. Party 1 just sends = +R1 to party 2.<br> +> 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> +> <br> +> Party 1 never learns the final value of (R,s1+s2) or m.<br> +> <br> +> Any comments on this or potential issues would be appreciated.<br> +> <br> +> Tom<br> +_______________________________________________<br> +bitcoin-dev mailing list<br> +<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" = +rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a><br> +<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = +rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati= +on.org/mailman/listinfo/bitcoin-dev</a><br> +</blockquote></div> + +--000000000000ea5a3106013c6113-- + |