@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 wanted to mention (using your notation):

in s1 = c * a1 * x1 + r1, you expressed the idea that the challenge c could be given to the server, to construct s1, but since a1 = 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 a1X1 + 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 server 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 proof 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 the face of it, that is what's needed).

@Jonas, Erik:
'posk' is probably meant as 'proof of secret key' which may(?) be a mixup with what is sometimes referred to in the literature as "KOSK" (iirc they 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 block 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 prevent 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 the 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] := R1[i] + R2[i] for all i <= K-1
> R[K] := R1[0] + ... + R1[K-1]
> c[i] := H(X, R[i], m[i]) for all i <= K.
> Using Wagner's algorithm, choose R2[0], ..., R2[K-1] such that
> c[0] + ... + c[K-1] = c[K].
> - Send c[0], ..., c[K-1] to the server to obtain s[0], ..., s[K-1].
> - Let
> s[K] = s[0] + ... + s[K-1].
> Then (s[K], R[K]) is a valid signature from the server, since
> s[K]G = 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 = k1G
> - Client sends c to the server and proves in zero knowledge that c =
> SHA256(X1 + X2, R1 + R2, m).
> - Server replies with s1 = 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