Date: Thu, 27 Jul 2023 05:51:14 +0000
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
Subject: Re: [bitcoin-dev] Blinded 2-party Musig2
Precedence: list

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