From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id EB76CC0032 for ; Wed, 30 Aug 2023 10:52:20 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id B2C4861043 for ; Wed, 30 Aug 2023 10:52:20 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org B2C4861043 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=k9T67JHF 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 dcIXzZ4q-oLx for ; Wed, 30 Aug 2023 10:52:19 +0000 (UTC) Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) by smtp3.osuosl.org (Postfix) with ESMTPS id C6BEF61041 for ; Wed, 30 Aug 2023 10:52:18 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org C6BEF61041 Received: by mail-ej1-x62f.google.com with SMTP id a640c23a62f3a-99de884ad25so733256366b.3 for ; Wed, 30 Aug 2023 03:52:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=commerceblock-com.20221208.gappssmtp.com; s=20221208; t=1693392736; x=1693997536; darn=lists.linuxfoundation.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=JVbTdBZfjRNo69IVEAn3huZSZeyIiG3ScGdlYRfLY4Y=; b=k9T67JHF3nhFfDGta9BDM9d06zVUKyEd5y1F0cf6/MA9jc5bGOfkqEBagMNIbTBQx1 EIDBuLrhOMnA4VyY12cvEqRVzooCcVpva/xBVqCFcn9AiB75wGkilt5140TN7uztTkjC dXax9NbatKTTjbEKb5zWeOYF2Vc+dyE9r9Pbym8Ifaaizx2WI767UHYXqb/9/hSvsLH/ svU3S0OQc6pw+N8qpuhq9Et939Bw/hrW8sLnXmsNfgbk+MeowIvO2JWRm2yOiB9Ffzpg B3Gzr1Ga96pxFD8UQ4ULkuraHcYtRFv+Isj0d5tNVZhAJ9a6bTuepvDwMyIPXJguVfu4 MZwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693392736; x=1693997536; 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=JVbTdBZfjRNo69IVEAn3huZSZeyIiG3ScGdlYRfLY4Y=; b=O7JIcEPD3h/b3MD1bkO21XZ77pPzWSyxkmf66eWAqSI3Jv0uhMgXyvDE9Q01ZYRYcq ESEwe960SD6kY+q2tvc8COzx9puimbqeWytTbARbE6mVIme0+FvSFKSWl78U0YN8xKDk BejYiMkamnG9lJZIEmw9koc1tO77lq6hHXJAVqU+iSR/UB1WWvvpZC0RHVydBQCDHv9u aVhpWy0qOUc2r+Iky/WE984tJCN6o+njJkxScpQilbQLt1tuhSoGvUwqv/VD3TopAbKy dRKzPdUNb/0YwyFTG5P1upPCh9dGXrrvAG+zZWVUvGAcIXDcZCCCwVxdq30what57PtP Z2ig== X-Gm-Message-State: AOJu0YyztyDg1b4Rm25u8h2w9Y+NGiWAx8g5XkB0yG/Zqbo2QLkiT4O+ 78jEN1I6dabTD4OJ56KxoKb3SY4xVWkWnYl6J6iT46GlYOz+GD+H/A== X-Google-Smtp-Source: AGHT+IGvDTyqvezP/4xIhE7+BT8rc/61wZccvpx+nKHoBPx5bvNia628kia2IaWkEpshQkcCfuYcTsDdHhfbNiwPweI= X-Received: by 2002:a17:907:9408:b0:9a1:cbe4:d029 with SMTP id dk8-20020a170907940800b009a1cbe4d029mr1831072ejc.74.1693392736250; Wed, 30 Aug 2023 03:52:16 -0700 (PDT) MIME-Version: 1.0 References: <7eae57c9-be42-ae07-9296-ae9e8e03c1b8@gmail.com> In-Reply-To: From: Tom Trevethan Date: Wed, 30 Aug 2023 11:52:05 +0100 Message-ID: To: Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="0000000000008280ba060421b835" X-Mailman-Approved-At: Wed, 30 Aug 2023 15:15:56 +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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2023 10:52:21 -0000 --0000000000008280ba060421b835 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable An update on progress on the development of the blinded two-party Schnorr scheme for statechains. As stated previously, we believe that one-more-signature and Wagner attacks are mitigated by the client committing the values of the blinding nonce used (labeled f) and the value of R2 used in a signing session to the server before the server responds with their value of R1. Then each time the generated signature is verified (in our application this is a new statecoin owner), the verifier retrieves the commitments and blinded challenge value from the server (c, SHA256(f) and SHA256(R2)) and f and R2 from the co-signer, and verifies that the blinded challenge value c =3D f + SHA256(X, R1 + R2 + f.X, m) and the commitments match f,R2. This ensures the signer cannot have chosen the values of f and R2 after the value of R1 is randomly generated by the server. This scheme has been implemented in a forked version of the secp256k1-zkp library: https://github.com/ssantos21/secp256k1-zkp where a new function has been added secp256k1_blinded_musig_nonce_process ( https://github.com/ssantos21/secp256k1-zkp/blob/ed08ad7603f211fdf39b5f6db9d= 7e99cf048a56c/src/modules/musig/session_impl.h#L580 ) which is required for the client generation of the blinded challenge value. One issue that came up and had to be solved was ensuring the R (curve point) is even (in MuSig2 the secret nonce is negated if R is odd) with the point f.X added (and f committed to). We will add a complete explanation of this to the updated spec. The scheme is implemented in a blind server: https://github.com/ssantos21/blinded-musig-sgx-server And client: https://github.com/ssantos21/blinded-musig2-client Any comments or questions appreciated. On Mon, Aug 7, 2023 at 1:55=E2=80=AFAM Tom Trevethan wrote: > A follow up to this, I have updated the blinded statechain protocol > description to include the mitigation to the Wagner attack by requiring t= he > server to send R1 values only after commitments made to the server of the > R2 values used by the user, and that all the previous computed c values a= re > verified by each new statecoin owner. > https://github.com/commerceblock/mercury/blob/master/layer/protocol.md > > Essentially, the attack is possible because the server cannot verify that > the blinded challenge (c) value it has been sent by the user has been > computed honestly (i.e. c =3D SHA256(X1 + X2, R1 + R2, m) ), however this= CAN > be verified by each new owner of a statecoin for all the previous > signatures. > > Each time an owner cooperates with the server to generate a signature on = a > backup tx, the server will require that the owner send a commitment to > their R2 value: e.g. SHA256(R2). The server will store this value before > responding with it's R1 value. This way, the owner cannot choose the valu= e > of R2 (and hence c). > > When the statecoin is received by a new owner, they will receive ALL > previous signed backup txs for that coin from the sender, and all the > corresponding R2 values used for each signature. They will then ask the > server (for each previous signature), the commitments SHA256(R2) and the > corresponding server generated R1 value and c value used. The new owner > will then verify that each backup tx is valid, and that each c value was > computed c =3D SHA256(X1 + X2, R1 + R2, m) and each commitment equals > SHA256(R2). This ensures that a previous owner could not have generated > more valid signatures than the server has partially signed. > > On Thu, Jul 27, 2023 at 2:25=E2=80=AFPM Tom Trevethan > wrote: > >> >> On Thu, Jul 27, 2023 at 9:08=E2=80=AFAM Jonas Nick wrote: >> >>> No, proof of knowledge of the r values used to generate each R does not >>> prevent >>> Wagner's attack. I wrote >>> >>> > Using Wagner's algorithm, choose R2[0], ..., R2[K-1] such that >>> > c[0] + ... + c[K-1] =3D c[K]. >>> >>> You can think of this as actually choosing scalars r2[0], ..., r2[K-1] >>> and >>> define R2[i] =3D r2[i]*G. The attacker chooses r2[i]. The attack wouldn= 't >>> make >>> sense if he didn't. >>> >> --0000000000008280ba060421b835 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
An update on progress on the development of the blinded tw= o-party Schnorr scheme for statechains.=C2=A0

As stated = previously, we believe that one-more-signature and Wagner attacks are mitig= ated by the client=C2=A0committing=C2=A0the values of the blinding nonce us= ed (labeled f) and the value of R2 used in a signing session to the server = before the server responds with their value of R1. Then each time the gener= ated signature is verified (in our application this is a new statecoin owne= r), the verifier retrieves the commitments and blinded challenge value from= the server (c, SHA256(f) and SHA256(R2)) and f and R2 from the co-signer, = and verifies that the blinded challenge value c =3D f=C2=A0+ SHA256(X, R1 + R2 + f.X, m) and t= he commitments match f,R2. This ensures the signer cannot have chosen the v= alues of f and R2 after the value of R1 is randomly generated by the server= .=C2=A0=C2=A0

This scheme has been implemented in = a forked version of the secp256k1-zkp library: https://github.com/ssantos21/secp256k1-zkp w= here a new function has been added secp256k1_blinded_musig_nonce_process ( = https://git= hub.com/ssantos21/secp256k1-zkp/blob/ed08ad7603f211fdf39b5f6db9d7e99cf048a5= 6c/src/modules/musig/session_impl.h#L580 ) which is required for the cl= ient generation of the blinded challenge value.=C2=A0

<= div>One issue that came up and had to be solved was ensuring the R (curve p= oint) is even (in MuSig2 the secret nonce is negated if R is odd) with the = point f.X added (and f committed to). We will add a complete explanation of= this to the updated spec.=C2=A0

The scheme is imp= lemented=C2=A0in a blind server:

And client:

Any commen= ts or questions appreciated.=C2=A0

On Mon, Aug 7, 2023 at 1:55=E2=80= =AFAM Tom Trevethan <tom@commer= ceblock.com> wrote:
A follow up to this, I have updated the bl= inded statechain protocol description to include the mitigation to the Wagn= er attack by requiring=C2=A0the server to send R1 values only after commitm= ents made to the server of the R2 values used by the user, and that all the= previous computed c values are verified by each new statecoin=C2=A0owner.= =C2=A0

Essenti= ally, the attack is possible because the server cannot verify that the blin= ded challenge (c) value it has been sent by the user has been computed hone= stly=C2=A0(i.e. c =3D SHA256(X1 + X2, R1 + R2, m) ), however this CAN be ve= rified by each new owner of a statecoin=C2=A0for all the previous signature= s.=C2=A0

Each time an owner cooperates with the se= rver to generate a signature on a backup tx, the server will require that t= he owner send a commitment to their R2 value: e.g. SHA256(R2). The server w= ill store this value before responding with it's R1 value. This way, th= e owner cannot choose the value of R2 (and hence c).=C2=A0

When the statecoin is received by a new owner, they will receive A= LL previous signed backup txs for that coin from the sender, and all the co= rresponding R2 values used for each signature. They will then ask the serve= r (for each previous signature), the commitments SHA256(R2) and the corresp= onding server generated R1 value and c value used. The new owner will then = verify that each backup tx is valid, and that each c value was computed c = =3D SHA256(X1 + X2, R1 + R2, m)=C2=A0 and each commitment equals SHA256(R2)= . This ensures that a previous owner could not have generated more valid si= gnatures than the server has partially signed.=C2=A0

On Thu, Jul = 27, 2023 at 2:25=E2=80=AFPM Tom Trevethan <tom@commerceblock.com> wrote:

On Thu, Jul 27, 2023 at 9:08=E2= =80=AFAM Jonas Nick <jonasdnick@gmail.com> wrote:
No, proof of knowledge of the r values used to g= enerate each R does not prevent
Wagner's attack. I wrote

=C2=A0>=C2=A0 =C2=A0Using Wagner's algorithm, choose R2[0], ..., R2[= K-1] such that
=C2=A0>=C2=A0 =C2=A0 c[0] + ... + c[K-1] =3D c[K].

You can think of this as actually choosing scalars r2[0], ..., r2[K-1] and<= br> define R2[i] =3D r2[i]*G. The attacker chooses r2[i]. The attack wouldn'= ;t make
sense if he didn't.
--0000000000008280ba060421b835--