📅 Original date posted:2021-10-09
📝 Original message:
Hi,
it seems like parts of this proposal rely on deterministic nonces in MuSig.
Generally, this is insecure unless combined with heavy machinery that proves
correctness of the nonce derivation in zero knowledge. If one signer uses
deterministic nonces and another signer uses random nonces, then two signing
sessions will have different challenge hashes which results in nonce reuse by
the first signer [0]. Is there a countermeasure against this attack in the
proposal? What are the inputs to the function that derive DA1, DA2? Is the
assumption that a signer will not sign the same message more than once?
It may be worth pointing out that an adaptor signature scheme can not treat
MuSig2 as a black box as indicated in the "Adaptor Signatures" section [1]. In
particular, generally the secret X must be input to the hash function that
generates nonce coefficient k. Otherwise, an attacker can grind through
challenge hashes by varying X without affecting the aggregate nonce and produce
a forgery. For the same reason, the message m is included in hash function
inputs of k. However, taking X into account when computing k shouldn't be an
issue for protocols making use of adaptor signatures because k does not need to
be determined before signing time and X is required to be known at that point
anyway.
[0] https://medium.com/blockstream/musig-dn-schnorr-multisignatures-with-verifiably-deterministic-nonces-27424b5df9d6
See "The attack works as follows."
[1] MuSig2 adaptor signature issue: https://github.com/ElementsProject/scriptless-scripts/issues/23,
PR: https://github.com/ElementsProject/scriptless-scripts/pull/24
Jonas Nick [ARCHIVE] /
npub1at…y3z5a
2023-06-09 13:04:07
in reply to nevent1q…xm5q
Author Public Key
npub1at3pav59gkeqz9kegzqhk2v4j4r435x42ytf23pxs8crt74tuc8s2y3z5aPublished at
2023-06-09 13:04:07Event JSON
{
"id": "cb0bc2b2e0a14765139e83b32ad75a71dd854ea60bbb6f68e550288df9980be2",
"pubkey": "eae21eb28545b20116d940817b2995954758d0d5511695442681f035faabe60f",
"created_at": 1686315847,
"kind": 1,
"tags": [
[
"e",
"bfc4ed728b228b9341f3493f5bd7d935423e85bd9d039717f691001784a42238",
"",
"root"
],
[
"e",
"763af3c056cd2f62565729e65e4597ccb5881bcf852e3a3ee69fe57f294cb35b",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "📅 Original date posted:2021-10-09\n📝 Original message:\nHi,\n\nit seems like parts of this proposal rely on deterministic nonces in MuSig.\nGenerally, this is insecure unless combined with heavy machinery that proves\ncorrectness of the nonce derivation in zero knowledge. If one signer uses\ndeterministic nonces and another signer uses random nonces, then two signing\nsessions will have different challenge hashes which results in nonce reuse by\nthe first signer [0]. Is there a countermeasure against this attack in the\nproposal? What are the inputs to the function that derive DA1, DA2? Is the\nassumption that a signer will not sign the same message more than once?\n\nIt may be worth pointing out that an adaptor signature scheme can not treat\nMuSig2 as a black box as indicated in the \"Adaptor Signatures\" section [1]. In\nparticular, generally the secret X must be input to the hash function that\ngenerates nonce coefficient k. Otherwise, an attacker can grind through\nchallenge hashes by varying X without affecting the aggregate nonce and produce\na forgery. For the same reason, the message m is included in hash function\ninputs of k. However, taking X into account when computing k shouldn't be an\nissue for protocols making use of adaptor signatures because k does not need to\nbe determined before signing time and X is required to be known at that point\nanyway.\n\n[0] https://medium.com/blockstream/musig-dn-schnorr-multisignatures-with-verifiably-deterministic-nonces-27424b5df9d6\n See \"The attack works as follows.\"\n[1] MuSig2 adaptor signature issue: https://github.com/ElementsProject/scriptless-scripts/issues/23,\n PR: https://github.com/ElementsProject/scriptless-scripts/pull/24",
"sig": "03fe08fe472c3eaa443a758aa656c480c62edfc70933f0d76472bc52cd52ab19c531c797a51dded32c5290256e08970ee9a0010fa4b5de932bbe06d92d4c6bd6"
}