rich1.0Erik Aronesty [ARCHIVE] (npub1y2…5taj0)https://yabu.me/npub1y22yec0znyzw8qndy5qn5c2wgejkj0k9zsqra7kvrd6cd6896z4qm5taj0njumphttps://yabu.me📅 Original date posted:2023-07-24 🗒️ Summary of this message: The email discusses the potential vulnerabilities of a proposed scheme and suggests an alternative approach that may be worth exploring. 📝 Original message: You can't choose R if you provide posk On Mon, Jul 24, 2023 at 10:31 AM Jonas Nick via bitcoin-dev < bitcoin-dev at 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]*a1*X1, > 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 = k1*G > - 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 at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230724/fc27bc0b/attachment-0001.html>