Date: Wed, 26 Jul 2023 19:19:44 +0000
To: moonsettler <moonsettler@protonmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: AdamISZ <AdamISZ@protonmail.com>
Message-ID: <cxOYS8sb23ZEN0txrLfT5nyJBuwk06I-Zo7SdzVifb4Am2dgVSlcwF2JXYIIRDsHfSyB0AMv5EeyHEVUboHAXfZg39RbrNhff-d1PKJzLq0=@protonmail.com>
In-Reply-To: <O3LTbUbjNa3SLUfJzSKDNLBCIhED_6rdOcmgLpYB9byX6HBVg3BMu3hrvY37fH4SGL8th8oJaVV6_ogl_ZOA0qTXgENq8xqQNSRB-VsHem4=@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>
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

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 blind-=
signing server has no other function than to check the 2FA?

This makes it different from most uses of blind signing, where *counting* t=
he number of signatures matters (hence 'one more forgery etc). Here, you ar=
e just saying "I'll sign whatever the heck you like, as long as you're auth=
orized with this 2FA procedure".

Going to ignore the details of practically what that means - though I'm sur=
e that's where most of the discussion would end up - but just looking at yo=
ur protocol in the gist:

It seems you're not checking K values against attacks, so for example this =
would allow someone to extract the server's key from one signing:

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.

So since s =3D k + ex =3D (k' + bx) + ex =3D k' + e'x, and you know s, k' a=
nd e', you can derive x. Then x2 =3D x - x1.

(Gist I'm referring to: https://gist.github.com/moonsettler/05f5948291ba8db=
a63a3985b786233bb)




Sent with Proton Mail secure email.

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


> Hi All,
>=20
> I believe it's fairly simple to solve the blinding (sorry for the bastard=
 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 if I =
got it wrong!
>=20
> BR,
> moonsettler
>=20
>=20
> ------- Original Message -------
> On Monday, July 24th, 2023 at 5:39 PM, Jonas Nick via bitcoin-dev bitcoin=
-dev@lists.linuxfoundation.org wrote:
>=20
>=20
>=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 server (=
party 1)
> > received some c during the signature protocol. Can't the server scan th=
e
> > 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 the se=
rver 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