path: root/4e/de34d9fd9ee43b24a247a2e24eebc09e1db6dc

Return-Path: <AdamISZ@protonmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 12707C0032
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 27 Jul 2023 05:51:42 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id CCA2D41E65
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 27 Jul 2023 05:51:41 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org CCA2D41E65
Authentication-Results: smtp4.osuosl.org;
 dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com
 header.a=rsa-sha256 header.s=protonmail3 header.b=mV48eif0
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level: 
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 SPF_HELO_PASS=-0.001, SPF_PASS=-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 AyIe7Nz5YnaQ
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 27 Jul 2023 05:51:40 +0000 (UTC)
Received: from mail-41103.protonmail.ch (mail-41103.protonmail.ch
 [185.70.41.103])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 36DB541E6D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 27 Jul 2023 05:51:40 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 36DB541E6D
Date: Thu, 27 Jul 2023 05:51:14 +0000
Authentication-Results: mail-41103.protonmail.ch;
 dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com
 header.b="mV48eif0"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=protonmail3; t=1690437088; x=1690696288;
 bh=Fe62Rm5XEOsFr7AOrMMJWEMs0UxF0N9OKQW0LvVCV1g=;
 h=Date:To:From:Subject:Message-ID:In-Reply-To:References:
 Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
 Message-ID:BIMI-Selector;
 b=mV48eif0tX9YVmf/wmP3O0TvjQLl33yRbyKwpR69rxOBS64zol5WCEDcV1zt2yCqX
 1JTDrUxNxRzr+CL8afR0s/xduFK6MKAFwJJtPZisIkQVocE31hzejyyvwkPbaXkpGS
 +GtpTP8XLSAXRReOfhWUR4hu0Zu2PGa3jKqWXxr1G88b/CAOjHhxM5LCMqS1A1X8R2
 AZMEhm8DY0eXg2ecLBGuM4gMHtUz+KLA1a1fOSg7mFOrE9CIkM8w7ihJUWB0v8SGOw
 5nLHdSkASH2slemT/ggs8V6MTAnLqjvOkdpC93vdWWjH420SBvAweO0yBrN70iQ3Dj
 2/1LsRPuIiCCA==
To: moonsettler <moonsettler@protonmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: AdamISZ <AdamISZ@protonmail.com>
Message-ID: <LBcOp2w_wV3Q2X_tP94SfaYbqxiEwKP8hPUbgT_b1dQeHT3hPw6y6o3kFYep9wgqsjIWj1g8jUHzaZFdYTgL7eLwO22-70b7SB0dO7Ml7Zk=@protonmail.com>
In-Reply-To: <NUH-svf2Bz96uxe5zYehmG8sQ7uLc3GwlFSBrN3-Sdfroj0iL4C2bTV2vxqAsFM9yHr7fi0C_74ThNPGKerQAuDlW2b0ljwXud_uiUDQ8RA=@protonmail.com>
References: <CAJvkSsc_rKneeVrLkTqXJDKcr+VQNBHVJyXVe=7PkkTZ+SruFQ@mail.gmail.com>
 <b770096c-e8c4-70f7-8cd7-d74c27181413@gmail.com>
 <O3LTbUbjNa3SLUfJzSKDNLBCIhED_6rdOcmgLpYB9byX6HBVg3BMu3hrvY37fH4SGL8th8oJaVV6_ogl_ZOA0qTXgENq8xqQNSRB-VsHem4=@protonmail.com>
 <cxOYS8sb23ZEN0txrLfT5nyJBuwk06I-Zo7SdzVifb4Am2dgVSlcwF2JXYIIRDsHfSyB0AMv5EeyHEVUboHAXfZg39RbrNhff-d1PKJzLq0=@protonmail.com>
 <NUH-svf2Bz96uxe5zYehmG8sQ7uLc3GwlFSBrN3-Sdfroj0iL4C2bTV2vxqAsFM9yHr7fi0C_74ThNPGKerQAuDlW2b0ljwXud_uiUDQ8RA=@protonmail.com>
Feedback-ID: 11565511:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Thu, 27 Jul 2023 08:29:00 +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: Thu, 27 Jul 2023 05:51:42 -0000

A reasonable attack scenario might be: attacker gains control of client mac=
hine and its privkey, wants to extract money. It first operates passively, =
waiting for user to do 2FA on a normal transaction, only modifying the nonc=
e used in order to achieve its goal. Then, after that 1 transaction goes th=
rough, it gets the server privkey as above, and so 2FA is no longer needed =
to steal the remainder of the money. Or did I miss some part of the setup?


Sent with Proton Mail secure email.

------- Original Message -------
On Wednesday, July 26th, 2023 at 13:28, moonsettler via bitcoin-dev <bitcoi=
n-dev@lists.linuxfoundation.org> wrote:


> Yes, thank you!
>=20
> There I assume if someone has your private key, and can satisfy the 2FA, =
he will just steal your coins, and not bother with extracting the co-signer=
s key that is specific to you. I can see, how this assumption is not useful=
 generally.
>=20
> BR,
> moonsettler
>=20
> Sent with Proton Mail secure email.
>=20
>=20
> ------- Original Message -------
> On Wednesday, July 26th, 2023 at 9:19 PM, AdamISZ AdamISZ@protonmail.com =
wrote:
>=20
>=20
>=20
> > It's an interesting idea for a protocol. If I get it right, your basic =
idea here is to kind of "shoehorn" in a 2FA authentication, and that the bl=
ind-signing server has no other function than to check the 2FA?
> >=20
> > This makes it different from most uses of blind signing, where counting=
 the number of signatures matters (hence 'one more forgery etc). Here, you =
are just saying "I'll sign whatever the heck you like, as long as you're au=
thorized with this 2FA procedure".
> >=20
> > Going to ignore the details of practically what that means - though I'm=
 sure that's where most of the discussion would end up - but just looking a=
t your protocol in the gist:
> >=20
> > It seems you're not checking K values against attacks, so for example t=
his would allow someone to extract the server's key from one signing:
> >=20
> > 1 Alice, after receiving K2, sets K1 =3D K1' - K2, where the secret key=
 of K1' is k1'.
> > 2 Chooses b as normal, sends e' as normal.
> > 3 Receiving s2, calculate s =3D s1 + s2 as normal.
> >=20
> > So since s =3D k + ex =3D (k' + bx) + ex =3D k' + e'x, and you know s, =
k' and e', you can derive x. Then x2 =3D x - x1.
> >=20
> > (Gist I'm referring to: https://gist.github.com/moonsettler/05f5948291b=
a8dba63a3985b786233bb)
> >=20
> > Sent with Proton Mail secure email.
> >=20
> > ------- Original Message -------
> > On Wednesday, July 26th, 2023 at 03:44, moonsettler via bitcoin-dev bit=
coin-dev@lists.linuxfoundation.org wrote:
> >=20
> > > Hi All,
> > >=20
> > > I believe it's fairly simple to solve the blinding (sorry for the bas=
tard notation!):
> > >=20
> > > Signing:
> > >=20
> > > X =3D X1 + X2
> > > K1 =3D k1G
> > > K2 =3D k2G
> > >=20
> > > R =3D K1 + K2 + bX
> > > e =3D hash(R||X||m)
> > >=20
> > > e' =3D e + b
> > > s =3D (k1 + e'*x1) + (k2 + e'*x2)
> > > s =3D (k1 + k2 + b(x1 + x2)) + e(x1 + x2)
> > >=20
> > > sG =3D (K1 + K2 + bX) + eX
> > > sG =3D R + eX
> > >=20
> > > Verification:
> > >=20
> > > Rv =3D sG - eX
> > > ev =3D hash(R||X||m)
> > > e ?=3D ev
> > >=20
> > > https://gist.github.com/moonsettler/05f5948291ba8dba63a3985b786233bb
> > >=20
> > > Been trying to get a review on this for a while, please let me know i=
f I got it wrong!
> > >=20
> > > BR,
> > > moonsettler
> > >=20
> > > ------- Original Message -------
> > > On Monday, July 24th, 2023 at 5:39 PM, Jonas Nick via bitcoin-dev bit=
coin-dev@lists.linuxfoundation.org wrote:
> > >=20
> > > > > Party 1 never learns the final value of (R,s1+s2) or m.
> > > >=20
> > > > Actually, it seems like a blinding step is missing. Assume the serv=
er (party 1)
> > > > received some c during the signature protocol. Can't the server sca=
n the
> > > > blockchain for signatures, compute corresponding hashes c' =3D H(R|=
|X||m) as in
> > > > signature verification and then check c =3D=3D c'? If true, then th=
e server has the
> > > > preimage for the c received from the client, including m.
> > > > _______________________________________________
> > > > bitcoin-dev mailing list
> > > > bitcoin-dev@lists.linuxfoundation.org
> > > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > >=20
> > > _______________________________________________
> > > bitcoin-dev mailing list
> > > bitcoin-dev@lists.linuxfoundation.org
> > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev