diff options
| author | Tom Trevethan <tom@commerceblock.com> | 2023-07-25 17:05:48 +0100 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2023-07-25 16:06:04 +0000 |
| commit | 5ca764f55da0c331a793bb250c9f773210c169c3 (patch) | |
| tree | a5de14e87e18516b0d4166d49103a3c8eb6d95b9 | |
| parent | e815e7d3279b18196219eb653162ac3d6e446289 (diff) | |
| download | pi-bitcoindev-5ca764f55da0c331a793bb250c9f773210c169c3.tar.gz pi-bitcoindev-5ca764f55da0c331a793bb250c9f773210c169c3.zip | |
Re: [bitcoin-dev] Blinded 2-party Musig2
| -rw-r--r-- | 48/cbab32f34814aea960df8946ba8f59474d1723 | 471 |
1 files changed, 471 insertions, 0 deletions
diff --git a/48/cbab32f34814aea960df8946ba8f59474d1723 b/48/cbab32f34814aea960df8946ba8f59474d1723 new file mode 100644 index 000000000..76a6e5694 --- /dev/null +++ b/48/cbab32f34814aea960df8946ba8f59474d1723 @@ -0,0 +1,471 @@ +Return-Path: <tom@commerceblock.com> +Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 87DC0C0032 + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 25 Jul 2023 16:06:04 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp4.osuosl.org (Postfix) with ESMTP id 52CC340980 + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 25 Jul 2023 16:06:04 +0000 (UTC) +DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 52CC340980 +Authentication-Results: smtp4.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=gxu/SBH6 +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 smtp4.osuosl.org ([127.0.0.1]) + by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id sPpy18AhRDw8 + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 25 Jul 2023 16:06:02 +0000 (UTC) +Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com + [IPv6:2a00:1450:4864:20::52f]) + by smtp4.osuosl.org (Postfix) with ESMTPS id A5B144097A + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 25 Jul 2023 16:06:01 +0000 (UTC) +DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org A5B144097A +Received: by mail-ed1-x52f.google.com with SMTP id + 4fb4d7f45d1cf-51d95aed33aso8151189a12.3 + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 25 Jul 2023 09:06:01 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=commerceblock-com.20221208.gappssmtp.com; s=20221208; t=1690301159; + x=1690905959; + h=to:subject:message-id:date:from:in-reply-to:references:mime-version + :from:to:cc:subject:date:message-id:reply-to; + bh=cwIQutjVbkCblv74bsqbMRodjQnwImHYTMULAxoiNMc=; + b=gxu/SBH6E2HvX6PJ6nzao66wdvDgCMrPbli/0hRcB3oqA7yghdXMb9KaDNN//S+v3p + eDZNAT3i7KpG4mOFfdZH/MBEfQ11t4RP6wMM2rf3J6erMulWpKPLH0U8PUxTqfo/SaDc + Vc2qVJ3Cf0R7smfW+ROOhJMts0wcq8zLuHY0pQq9mcxj+yFTiwpy+LvttOmiZiXunxU9 + MqY1FH2uMHyvyKh4DndsS133cxUi9oQvqxLajpbyVhLPJnaSSE+53KEXYGPQGFymbn8L + mHkUa18qMCilOUWGpinSJy6Gs3Y28sOJjc+J+Q4JKzR452177HRhxVD0naLJ/szSEKpf + TKbA== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20221208; t=1690301159; x=1690905959; + 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=cwIQutjVbkCblv74bsqbMRodjQnwImHYTMULAxoiNMc=; + b=AkfX7o5jKuT5PbyoOK23mr6+DG3fhQXxuUgtxaXoFu4kPLvRf5f/XtQ0h2bk4fBat+ + 6YYWgezoE/xENJHldpeQvhF5uNNnlgz8RwXYiGMqXSKFRfp5CVEGmTPi6Lu8XaT+dlB6 + s888nN3EJkMU4SjZpwxGDHLYRua5dbY+ofAQ+yUGIsPh1dF2+OqV2p3NUao6mBFKLvAp + qw0T3R71ECOCcagmdGKpDFGhn4L7QKt9kdhU+TK5M1b1H+Hs3vDdQAaIDQBeCyYSIGga + 5FK9UR45afpsON/VKJi2FEs7RSO1q9DkgmY7Ydo8dL39HwESXAA+asqXDQ6Y5ZJlZnis + A1ww== +X-Gm-Message-State: ABy/qLY66vPs2+wVIZFy0RB5zlRUWKrcqShFgYBjOrNsbO1DkY5259aG + wZEj6+mUyNuo82lyjyfS6Iz300JIyLsoIfyjFgqT7oHNrPM/RACTlw== +X-Google-Smtp-Source: APBJJlGiDB2rG2PYQ5QBtLxl1Z176Jnyki22hSjUd9S3o4x+egURFf3jZVBeVijEuwYlAZ05m1fOEKIvZGfWSqdRrQY= +X-Received: by 2002:a17:906:30c3:b0:994:19ed:e92b with SMTP id + b3-20020a17090630c300b0099419ede92bmr11600421ejb.20.1690301159257; Tue, 25 + Jul 2023 09:05:59 -0700 (PDT) +MIME-Version: 1.0 +References: <CAJvkSsc_rKneeVrLkTqXJDKcr+VQNBHVJyXVe=7PkkTZ+SruFQ@mail.gmail.com> + <ca674cee-6fe9-f325-7e09-f3efda082b6b@gmail.com> + <YwMiFAEImHAJfAHHU7WbN1C1JuHjh0vC18Hn61QplFOlY5mEgKmjsAlj2geV1-28E36_wgfL9_QHTRJsbtOLt73o9C4JfoVt8scvYGzKHOI=@protonmail.com> + <CAJowKgJ61nWBHMfNVx7J+C1QwZZMQ9zUaFQnAw1roXiPfi5O6A@mail.gmail.com> +In-Reply-To: <CAJowKgJ61nWBHMfNVx7J+C1QwZZMQ9zUaFQnAw1roXiPfi5O6A@mail.gmail.com> +From: Tom Trevethan <tom@commerceblock.com> +Date: Tue, 25 Jul 2023 17:05:48 +0100 +Message-ID: <CAJvkSsdAVFf44XXXXhXqV7JcnmV796vttHEtNEp=v-zxehUofw@mail.gmail.com> +To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Content-Type: multipart/alternative; boundary="000000000000296970060151e850" +X-Mailman-Approved-At: Tue, 25 Jul 2023 21:18:41 +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: Tue, 25 Jul 2023 16:06:04 -0000 + +--000000000000296970060151e850 +Content-Type: text/plain; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +Thanks for the replies. As I understand it, the v=3D2 nonces signing protoc= +ol +of musig2 prevents the Wagner attack. Also, that the challenge value c must +be blinded from the server to prevent the server from being able to +determine the signature from the on-chain state. + +In addition, in order to update the server (party 1) keyshare when a +statecoin is transferred between users, the key aggregation coefficient +must be set to 1 for each key. The purpose of this coefficient in the +Musig2 protocol is to prevent 'rogue key attacks' where one party can +choose a public key derived from both their own secret key and the inverse +of the other party's public key giving them the ability to unilaterally +produce a valid signature over the aggregate key. However this can be +prevented by the party producing a proof of knowledge of the private key +corresponding to their supplied public key. This can be a signature, which +is produced in any case by signing the statechain state in the mercury +protocol. This signature must be verified by the receiver of a coin (who +must also verify the server pubkey combines with the sender pubkey to get +the coin address) which proves that the server is required to co-sign to +generate any signature for this address. + +Here is a modified protocol: + +Keygen: + +Server generates private key x1 and public key X1 =3D x1.G and sends X1 to +user (party 2) +User generates private key x2 and public key X2 =3D x2.G and (random) +blinding nonce z and computes the aggregate public key X =3D z.(X1 + X2) +(server never learns of X, X2 or z). + +Signing: + +Server generates nonces r11 and r12 and R11 =3D r11.G and R12 =3D r12.G and +sends R11 and R12 to the user. +User generates nonces r21 and r22 and R21 =3D r21.G and R22 =3D r22.G +User computes R1 =3D R11 + R21 and R2 =3D R12 + R22 and b =3D H(X,(R1,R2),m= +) and +R =3D R1 + b.R2 and c =3D (X,R,m) +User sends the values y =3D cz and b to the server. +Server computes s1 =3D yx1 + r11 + br12 and sends it to the user. +User computes s2 =3D yx2 + r21 + br22 and s =3D s1 + s2 and signature (s,R) + +Transfer: + +In a statecoin transfer, when receiving a statecoin, in order to verify +that the coin address (i.e. aggregate public key) is shared correctly +between the previous owner and the server, the client must verify the +following: + +Retrieve the CURRENT public key from the server for this coin X1. +Retrieve the public key X2 and the blinding nonce z from the sender. +Verify that z.X1 + X2 =3D P the address of the statecoin. +Verify that the sender has the private key used to generate X2: this is +done by verifying the statechain signature over the receiver public key X3 +from X2. +This proves that the address P was generated (aggregated) with the server +and can only be signed with cooperation with the server, i.e. no previous +owner can hold the full key. + +In order to update the key shares on transfer, the following protocol can +be used: + +Server (party 1) generates a random blinding nonce e and sends it to user. +User adds their private key to the nonce: t1 =3D e + x2 +Client sends t1 and z to the reciever as part of transfer_msg (encrypted +with the receiver public key X3 =3D x3.G). +Receiver client decrypts t1 and then subtracts their private key x3: t2 =3D= + e ++ x2 - x3. +Receiver client sends t2 to the server as part of transfer_receiver. +Server the updates the private key share x1_2 =3D x1 + t2 - e =3D x1 + e + = +x2 - +x3 - e =3D x1 + x2 - x3 +So now, x1_2 + x3 (the aggregation of the new server key share with the new +client key share) is equal to x1 + x2 (the aggregation of the old server +key share with the old client key share). +The server deletes x1. + +On Tue, Jul 25, 2023 at 3:12=E2=80=AFPM Erik Aronesty <erik@q32.com> wrote: + +> posk is "proof of secret key". so you cannot use wagner to select R +> +> On Mon, Jul 24, 2023 at 1:59=E2=80=AFPM AdamISZ via bitcoin-dev < +> bitcoin-dev@lists.linuxfoundation.org> wrote: +> +>> @ZmnSCPxj: +>> +>> yes, Wagner is the attack you were thinking of. +>> +>> And yeah, to avoid it, you should have the 3rd round of MuSig1, i.e. the +>> R commitments. +>> +>> @Tom: +>> As per above it seems you were more considering MuSig1 here, not MuSig2. +>> At least in this version. So you need the initial commitments to R. +>> +>> Jonas' reply clearly has covered a lot of what matters here, but I wante= +d +>> to mention (using your notation): +>> +>> in s1 =3D c * a1 * x1 + r1, you expressed the idea that the challenge c +>> could be given to the server, to construct s1, but since a1 =3D H(L, X1)= + and +>> L is the serialization of all (in this case, 2) keys, that wouldn't work +>> for blinding the final key, right? +>> But, is it possible that this addresses the other problem? +>> If the server is given c1*a1 instead as the challenge for signing (with +>> their "pure" key x1), then perhaps it avoids the issue? Given what's on = +the +>> blockchain ends up allowing calculation of 'c' and the aggregate key a1X= +1 + +>> a2X2, is it the case that you cannot find a1 and therefore you cannot +>> correlate the transaction with just the quantity 'c1*a1' which the serve= +r +>> sees? +>> +>> But I agree with Jonas that this is just the start, i.e. the fundamental +>> requirement of a blind signing scheme is there has to be some guarantee = +of +>> no 'one more forgery' possibility, so presumably there has to be some pr= +oof +>> that the signing request is 'well formed' (Jonas expresses it below as a +>> ZKP of a SHA2 preimage .. it does not seem pretty but I agree that on th= +e +>> face of it, that is what's needed). +>> +>> @Jonas, Erik: +>> 'posk' is probably meant as 'proof of secret key' which may(?) be a mixu= +p +>> with what is sometimes referred to in the literature as "KOSK" (iirc the= +y +>> used it in FROST for example). It isn't clear to me yet how that factors +>> into this scenario, although ofc it is for sure a potential building blo= +ck +>> of these constructions. +>> +>> Sent with Proton Mail secure email. +>> +>> ------- Original Message ------- +>> On Monday, July 24th, 2023 at 08:12, Jonas Nick via bitcoin-dev < +>> bitcoin-dev@lists.linuxfoundation.org> wrote: +>> +>> +>> > Hi Tom, +>> > +>> > I'm not convinced that this works. As far as I know blind musig is +>> still an open +>> > research problem. What the scheme you propose appears to try to preven= +t +>> is that +>> > the server signs K times, but the client ends up with K+1 Schnorr +>> signatures for +>> > the aggregate of the server's and the clients key. I think it's +>> possible to +>> > apply a variant of the attack that makes MuSig1 insecure if the nonce +>> commitment +>> > round was skipped or if the message isn't determined before sending th= +e +>> nonce. +>> > Here's how a malicious client would do that: +>> > +>> > - Obtain K R-values R1[0], ..., R1[K-1] from the server +>> > - Let +>> > R[i] :=3D R1[i] + R2[i] for all i <=3D K-1 +>> > R[K] :=3D R1[0] + ... + R1[K-1] +>> > c[i] :=3D H(X, R[i], m[i]) for all i <=3D K. +>> > Using Wagner's algorithm, choose R2[0], ..., R2[K-1] such that +>> > c[0] + ... + c[K-1] =3D c[K]. +>> > - Send c[0], ..., c[K-1] to the server to obtain s[0], ..., s[K-1]. +>> > - Let +>> > s[K] =3D s[0] + ... + s[K-1]. +>> > Then (s[K], R[K]) is a valid signature from the server, since +>> > s[K]G =3D R[K] + c[K]a1X1, +>> > which the client can complete to a signature for public key X. +>> > +>> > What may work in your case is the following scheme: +>> > - Client sends commitment to the public key X2, nonce R2 and message m +>> to the +>> > server. +>> > - Server replies with nonce R1 =3D k1G +>> > - Client sends c to the server and proves in zero knowledge that c =3D +>> > SHA256(X1 + X2, R1 + R2, m). +>> > - Server replies with s1 =3D k1 + c*x1 +>> > +>> > However, this is just some quick intuition and I'm not sure if this +>> actually +>> > works, but maybe worth exploring. +>> > _______________________________________________ +>> > bitcoin-dev mailing list +>> > bitcoin-dev@lists.linuxfoundation.org +>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +>> _______________________________________________ +>> bitcoin-dev mailing list +>> bitcoin-dev@lists.linuxfoundation.org +>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +>> +> + +--000000000000296970060151e850 +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr">Thanks for the replies. As I understand it, the v=3D2 nonc= +es signing protocol of musig2 prevents the Wagner attack. Also, that the ch= +allenge value c must be blinded from the server to prevent the server from = +being able to determine the signature from the on-chain state. <br><br>In a= +ddition, in order to update the server (party 1) keyshare when a statecoin = +is transferred between users, the key aggregation coefficient must be set t= +o 1 for each key. The purpose of this coefficient in the Musig2 protocol is= + to prevent 'rogue key attacks' where one party can choose a public= + key derived from both their own secret key and the inverse of the other pa= +rty's public key giving them the ability to unilaterally produce a vali= +d signature over the aggregate key. However this can be prevented by the pa= +rty producing a proof of knowledge of the private key corresponding to thei= +r supplied public key. This can be a signature, which is produced in any ca= +se by signing the statechain state in the mercury protocol. This signature = +must be verified by the receiver of a coin (who must also verify the server= + pubkey combines with the sender pubkey to get the coin address) which prov= +es that the server is required to co-sign to generate any signature for thi= +s address. <br><br>Here is a modified protocol:<br><br>Keygen:<br><br>Serve= +r generates private key x1 and public key X1 =3D x1.G and sends X1 to user = +(party 2)<br>User generates private key x2 and public key X2 =3D x2.G and (= +random) blinding nonce z and computes the aggregate public key X =3D z.(X1 = ++ X2) (server never learns of X, X2 or z). <br><br>Signing:<br><br>Server g= +enerates nonces r11 and r12 and R11 =3D r11.G and R12 =3D r12.G and sends R= +11 and R12 to the user. <br>User generates nonces r21 and r22 and R21 =3D r= +21.G and R22 =3D r22.G<br>User computes R1 =3D R11 + R21 and R2 =3D R12 + R= +22 and b =3D H(X,(R1,R2),m) and R =3D R1 + b.R2 and c =3D (X,R,m)<br>User s= +ends the values y =3D cz and b to the server. <br>Server computes s1 =3D yx= +1 + r11 + br12 and sends it to the user. <br>User computes s2 =3D yx2 + r21= + + br22 and s =3D s1 + s2 and signature (s,R)<br><br>Transfer:<br><br>In a = +statecoin transfer, when receiving a statecoin, in order to verify that the= + coin address (i.e. aggregate public key) is shared correctly between the p= +revious owner and the server, the client must verify the following:<br><br>= +Retrieve the CURRENT public key from the server for this coin X1.<br>Retrie= +ve the public key X2 and the blinding nonce z from the sender. <br>Verify t= +hat z.X1 + X2 =3D P the address of the statecoin.<br>Verify that the sender= + has the private key used to generate X2: this is done by verifying the sta= +techain signature over the receiver public key X3 from X2.<br>This proves t= +hat the address P was generated (aggregated) with the server and can only b= +e signed with cooperation with the server, i.e. no previous owner can hold = +the full key.<br><br>In order to update the key shares on transfer, the fol= +lowing protocol can be used:<br><br>Server (party 1) generates a random bli= +nding nonce e and sends it to user.<br>User adds their private key to the n= +once: t1 =3D e + x2<br>Client sends t1 and z to the reciever as part of tra= +nsfer_msg (encrypted with the receiver public key X3 =3D x3.G).<br>Receiver= + client decrypts t1 and then subtracts their private key x3: t2 =3D e + x2 = +- x3.<br>Receiver client sends t2 to the server as part of transfer_receive= +r.<br>Server the updates the private key share x1_2 =3D x1 + t2 - e =3D x1 = ++ e + x2 - x3 - e =3D x1 + x2 - x3<br>So now, x1_2 + x3 (the aggregation of= + the new server key share with the new client key share) is equal to x1 + x= +2 (the aggregation of the old server key share with the old client key shar= +e).<br>The server deletes x1.<br></div><br><div class=3D"gmail_quote"><div = +dir=3D"ltr" class=3D"gmail_attr">On Tue, Jul 25, 2023 at 3:12=E2=80=AFPM Er= +ik Aronesty <<a href=3D"mailto:erik@q32.com">erik@q32.com</a>> wrote:= +<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8= +ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr= +">posk is "proof of secret key".=C2=A0 =C2=A0so you cannot use wa= +gner to select R</div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class= +=3D"gmail_attr">On Mon, Jul 24, 2023 at 1:59=E2=80=AFPM AdamISZ via bitcoin= +-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D= +"_blank">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br></div><blo= +ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left= +:1px solid rgb(204,204,204);padding-left:1ex">@ZmnSCPxj:<br> +<br> +yes, Wagner is the attack you were thinking of.<br> +<br> +And yeah, to avoid it, you should have the 3rd round of MuSig1, i.e. the R = +commitments.<br> +<br> +@Tom:<br> +As per above it seems you were more considering MuSig1 here, not MuSig2. At= + least in this version. So you need the initial commitments to R.<br> +<br> +Jonas' reply clearly has covered a lot of what matters here, but I want= +ed to mention (using your notation):<br> +<br> +in s1 =3D c * a1 * x1 + r1, you expressed the idea that the challenge c cou= +ld be given to the server, to construct s1, but since a1 =3D H(L, X1) and L= + is the serialization of all (in this case, 2) keys, that wouldn't work= + for blinding the final key, right?<br> +But, is it possible that this addresses the other problem?<br> +If the server is given c1*a1 instead as the challenge for signing (with the= +ir "pure" key x1), then perhaps it avoids the issue? Given what&#= +39;s on the blockchain ends up allowing calculation of 'c' and the = +aggregate key a1X1 + a2X2, is it the case that you cannot find a1 and there= +fore you cannot correlate the transaction with just the quantity 'c1*a1= +' which the server sees?<br> +<br> +But I agree with Jonas that this is just the start, i.e. the fundamental re= +quirement of a blind signing scheme is there has to be some guarantee of no= + 'one more forgery' possibility, so presumably there has to be some= + proof that the signing request is 'well formed' (Jonas expresses i= +t below as a ZKP of a SHA2 preimage .. it does not seem pretty but I agree = +that on the face of it, that is what's needed).<br> +<br> +@Jonas, Erik:<br> +'posk' is probably meant as 'proof of secret key' which may= +(?) be a mixup with what is sometimes referred to in the literature as &quo= +t;KOSK" (iirc they used it in FROST for example). It isn't clear t= +o me yet how that factors into this scenario, although ofc it is for sure a= + potential building block of these constructions.<br> +<br> +Sent with Proton Mail secure email.<br> +<br> +------- Original Message -------<br> +On Monday, July 24th, 2023 at 08:12, Jonas Nick via bitcoin-dev <<a href= +=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin= +-dev@lists.linuxfoundation.org</a>> wrote:<br> +<br> +<br> +> Hi Tom,<br> +> <br> +> I'm not convinced that this works. As far as I know blind musig is= + still an open<br> +> research problem. What the scheme you propose appears to try to preven= +t is that<br> +> the server signs K times, but the client ends up with K+1 Schnorr sign= +atures for<br> +> the aggregate of the server's and the clients key. I think it'= +s possible to<br> +> apply a variant of the attack that makes MuSig1 insecure if the nonce = +commitment<br> +> round was skipped or if the message isn't determined before sendin= +g the nonce.<br> +> Here's how a malicious client would do that:<br> +> <br> +> - Obtain K R-values R1[0], ..., R1[K-1] from the server<br> +> - Let<br> +> R[i] :=3D R1[i] + R2[i] for all i <=3D K-1<br> +> R[K] :=3D R1[0] + ... + R1[K-1]<br> +> c[i] :=3D H(X, R[i], m[i]) for all i <=3D K.<br> +> Using Wagner's algorithm, choose R2[0], ..., R2[K-1] such that<br> +> c[0] + ... + c[K-1] =3D c[K].<br> +> - Send c[0], ..., c[K-1] to the server to obtain s[0], ..., s[K-1].<br= +> +> - Let<br> +> s[K] =3D s[0] + ... + s[K-1].<br> +> Then (s[K], R[K]) is a valid signature from the server, since<br> +> s[K]G =3D R[K] + c[K]a1X1,<br> +> which the client can complete to a signature for public key X.<br> +> <br> +> What may work in your case is the following scheme:<br> +> - Client sends commitment to the public key X2, nonce R2 and message m= + to the<br> +> server.<br> +> - Server replies with nonce R1 =3D k1G<br> +> - Client sends c to the server and proves in zero knowledge that c =3D= +<br> +> SHA256(X1 + X2, R1 + R2, m).<br> +> - Server replies with s1 =3D k1 + c*x1<br> +> <br> +> However, this is just some quick intuition and I'm not sure if thi= +s actually<br> +> works, but maybe worth exploring.<br> +> _______________________________________________<br> +> bitcoin-dev mailing list<br> +> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl= +ank">bitcoin-dev@lists.linuxfoundation.org</a><br> +> <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-= +dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org= +/mailman/listinfo/bitcoin-dev</a><br> +_______________________________________________<br> +bitcoin-dev mailing list<br> +<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">= +bitcoin-dev@lists.linuxfoundation.org</a><br> +<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = +rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail= +man/listinfo/bitcoin-dev</a><br> +</blockquote></div> +</blockquote></div> + +--000000000000296970060151e850-- + |