📅 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>;
Erik Aronesty [ARCHIVE] /
npub1y2…5taj0
2023-07-24 15:55:41
in reply to nevent1q…e97l
Author Public Key
npub1y22yec0znyzw8qndy5qn5c2wgejkj0k9zsqra7kvrd6cd6896z4qm5taj0Seen on
wss://relay.noswhere.comPublished at
2023-07-24 15:55:41Event JSON
{
"id": "46f7d3a9fafdde2e6c409d867b5c1af24b68a224d150f5178e9c0914c2fd97c6",
"pubkey": "22944ce1e29904e3826d25013a614e4665693ec514003efacc1b7586e8e5d0aa",
"created_at": 1690214141,
"kind": 1,
"tags": [
[
"e",
"86a87258a295f0e8a6ce06957ce368a6146cf45a73137d0af6fcc0729ce599a0",
"",
"root"
],
[
"e",
"3c8f294597c6632baf747f19d5a9e11a024097a93d2bd0a2c7149e10bd71383d",
"",
"reply"
],
[
"p",
"eae21eb28545b20116d940817b2995954758d0d5511695442681f035faabe60f"
]
],
"content": "📅 Original date posted:2023-07-24\n🗒️ Summary of this message: The email discusses the potential vulnerabilities of a proposed scheme and suggests an alternative approach that may be worth exploring.\n📝 Original message:\nYou can't choose R if you provide posk\n\nOn Mon, Jul 24, 2023 at 10:31 AM Jonas Nick via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Hi Tom,\n\u003e\n\u003e I'm not convinced that this works. As far as I know blind musig is still\n\u003e an open\n\u003e research problem. What the scheme you propose appears to try to prevent is\n\u003e that\n\u003e the server signs K times, but the client ends up with K+1 Schnorr\n\u003e signatures for\n\u003e the aggregate of the server's and the clients key. I think it's possible to\n\u003e apply a variant of the attack that makes MuSig1 insecure if the nonce\n\u003e commitment\n\u003e round was skipped or if the message isn't determined before sending the\n\u003e nonce.\n\u003e Here's how a malicious client would do that:\n\u003e\n\u003e - Obtain K R-values R1[0], ..., R1[K-1] from the server\n\u003e - Let\n\u003e R[i] := R1[i] + R2[i] for all i \u003c= K-1\n\u003e R[K] := R1[0] + ... + R1[K-1]\n\u003e c[i] := H(X, R[i], m[i]) for all i \u003c= K.\n\u003e Using Wagner's algorithm, choose R2[0], ..., R2[K-1] such that\n\u003e c[0] + ... + c[K-1] = c[K].\n\u003e - Send c[0], ..., c[K-1] to the server to obtain s[0], ..., s[K-1].\n\u003e - Let\n\u003e s[K] = s[0] + ... + s[K-1].\n\u003e Then (s[K], R[K]) is a valid signature from the server, since\n\u003e s[K]*G = R[K] + c[K]*a1*X1,\n\u003e which the client can complete to a signature for public key X.\n\u003e\n\u003e What may work in your case is the following scheme:\n\u003e - Client sends commitment to the public key X2, nonce R2 and message m to\n\u003e the\n\u003e server.\n\u003e - Server replies with nonce R1 = k1*G\n\u003e - Client sends c to the server and proves in zero knowledge that c =\n\u003e SHA256(X1 + X2, R1 + R2, m).\n\u003e - Server replies with s1 = k1 + c*x1\n\u003e\n\u003e However, this is just some quick intuition and I'm not sure if this\n\u003e actually\n\u003e works, but maybe worth exploring.\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230724/fc27bc0b/attachment-0001.html\u003e",
"sig": "5e7265be0a5ca501ca54b00297884e7a42eb362f7c2e6f9d20a3dc2dd1443fb43a97dc59584823b6e91b9cff9328fdf94141c0885a086f023b9c49ad2007de67"
}