📅 Original date posted:2023-05-01
🗒️ Summary of this message: A new analysis on the security of using signature adaptors for multiparty swaps has been posted on GitHub, focusing on scenarios of multiple adaptors at once or multiple signing sessions at once with the same adaptor. The analysis is based on MuSig and not MuSig2.
📝 Original message:Hi waxwing,
I think your view of the uselessness of single signer adaptors is too
pessimistic. The claim you make is that they "don't provide a way to
create enforcement that the publication of signature on a pre-defined
message will reveal a secret'' and so are useless. I think this is wrong.
If I hold a secret key for X and create a signature adaptor with some
encryption key Y with message m and do not create any further signatures
(adaptor or otherwise) on m, then any signature on m that is published
necessarily reveals the secret on Y to me. This is very useful and has
already been used for years by DLCs in production.
I haven't read the proofs in detail but I am optimistic about your
approach. One thing I was considering while reading is that you could make
a general proof against all secure Schnorr signing scheme in the ROM by
simply extending the ROM forwarding approach from Aumayer et al to all
"tweak" operations on the elements that go into the Schnorr challenge hash
i.e. the public key and the nonce. After all whether it's MuSig2, MuSig,
FROST they all must call some RO. I think we can prove that if we apply any
bijective map to the (X,R) tuple before they go into the challenge hash
function then any Schnorr-like scheme that was secure before will be secure
when bip32/TR tweaking (i.e. tweaking X) and adaptor tweaking (tweaking R)
is applied to it. This would be cool because then we could prove all these
variants secure for all schemes past and present in one go. I haven't got a
concrete approach but the proofs I've looked at all seem to share this
structure.
Cheers,
LL
On Sun, 30 Apr 2023 at 00:20, AdamISZ via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi list,
> I was motivated to look more carefully at the question of the security of
> using signature adaptors after recently getting quite enthused about the
> idea of using adaptors across N signing sessions to do a kind of multiparty
> swap. But of course security analysis is also much more important for the
> base case of 2 party swapping, which is of .. some considerable practical
> importance :)
>
> There is work (referenced in Section 3 here) that's pretty substantial on
> "how secure are adaptors" (think in terms of security reductions) already
> from I guess the 2019-2021 period. But I wanted to get into scenarios of
> multiple adaptors at once or multiple signing sessions at once with the
> *same* adaptor (as mentioned above, probably this is the most important
> scenario).
>
> To be clear this is the work of an amateur and is currently unreviewed -
> hence (a) me posting it here and (b) putting the paper on github so people
> can easily add specific corrections or comments if they like:
>
> https://github.com/AdamISZ/AdaptorSecurityDoc/blob/main/adaptorsecurity.pdf
>
> I'll note that I did the analysis only around MuSig, not MuSig2.
>
> The penultimate ("third case"), that as mentioned, of "multiple signing
> sessions, same adaptor" proved to be the most interesting: in trying to
> reduce this to ECDLP I found an issue around sequencing. It may just be
> irrelevant but I'd be curious to hear what others think about that.
>
> If nothing else, I'd be very interested to hear what experts in the field
> have to say about security reductions for this primitive in the case of
> multiple concurrent signing sessions (which of course has been analyzed
> very carefully already for base MuSig(2)).
>
> Cheers,
> AdamISZ/waxwing
>
>
>
>
> Sent with Proton Mail secure email.
> _______________________________________________
> 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/20230501/5c70f1ea/attachment.html>;
Lloyd Fournier [ARCHIVE] /
npub1kh…y05yp
2023-06-07 23:21:00
in reply to nevent1q…c8lm
Author Public Key
npub1khlhcuz0jrjwa0ayznq2q9agg4zvxfvx5x7jljrvwnpfzngrcf0q7y05ypPublished at
2023-06-07 23:21:00Event JSON
{
"id": "eff3e5cef7a8f76e573dfd1476b1713aece1b9f2619ebdee20dab4eec8ce2e42",
"pubkey": "b5ff7c704f90e4eebfa414c0a017a84544c32586a1bd2fc86c74c2914d03c25e",
"created_at": 1686180060,
"kind": 1,
"tags": [
[
"e",
"133df61ab9b4424d0555ee25d8e7699e138772505ef669b2f377570d0f54ea6b",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "📅 Original date posted:2023-05-01\n🗒️ Summary of this message: A new analysis on the security of using signature adaptors for multiparty swaps has been posted on GitHub, focusing on scenarios of multiple adaptors at once or multiple signing sessions at once with the same adaptor. The analysis is based on MuSig and not MuSig2.\n📝 Original message:Hi waxwing,\n\nI think your view of the uselessness of single signer adaptors is too\npessimistic. The claim you make is that they \"don't provide a way to\ncreate enforcement that the publication of signature on a pre-defined\nmessage will reveal a secret'' and so are useless. I think this is wrong.\nIf I hold a secret key for X and create a signature adaptor with some\nencryption key Y with message m and do not create any further signatures\n(adaptor or otherwise) on m, then any signature on m that is published\nnecessarily reveals the secret on Y to me. This is very useful and has\nalready been used for years by DLCs in production.\n\nI haven't read the proofs in detail but I am optimistic about your\napproach. One thing I was considering while reading is that you could make\na general proof against all secure Schnorr signing scheme in the ROM by\nsimply extending the ROM forwarding approach from Aumayer et al to all\n\"tweak\" operations on the elements that go into the Schnorr challenge hash\ni.e. the public key and the nonce. After all whether it's MuSig2, MuSig,\nFROST they all must call some RO. I think we can prove that if we apply any\nbijective map to the (X,R) tuple before they go into the challenge hash\nfunction then any Schnorr-like scheme that was secure before will be secure\nwhen bip32/TR tweaking (i.e. tweaking X) and adaptor tweaking (tweaking R)\nis applied to it. This would be cool because then we could prove all these\nvariants secure for all schemes past and present in one go. I haven't got a\nconcrete approach but the proofs I've looked at all seem to share this\nstructure.\n\nCheers,\n\nLL\n\nOn Sun, 30 Apr 2023 at 00:20, AdamISZ via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Hi list,\n\u003e I was motivated to look more carefully at the question of the security of\n\u003e using signature adaptors after recently getting quite enthused about the\n\u003e idea of using adaptors across N signing sessions to do a kind of multiparty\n\u003e swap. But of course security analysis is also much more important for the\n\u003e base case of 2 party swapping, which is of .. some considerable practical\n\u003e importance :)\n\u003e\n\u003e There is work (referenced in Section 3 here) that's pretty substantial on\n\u003e \"how secure are adaptors\" (think in terms of security reductions) already\n\u003e from I guess the 2019-2021 period. But I wanted to get into scenarios of\n\u003e multiple adaptors at once or multiple signing sessions at once with the\n\u003e *same* adaptor (as mentioned above, probably this is the most important\n\u003e scenario).\n\u003e\n\u003e To be clear this is the work of an amateur and is currently unreviewed -\n\u003e hence (a) me posting it here and (b) putting the paper on github so people\n\u003e can easily add specific corrections or comments if they like:\n\u003e\n\u003e https://github.com/AdamISZ/AdaptorSecurityDoc/blob/main/adaptorsecurity.pdf\n\u003e\n\u003e I'll note that I did the analysis only around MuSig, not MuSig2.\n\u003e\n\u003e The penultimate (\"third case\"), that as mentioned, of \"multiple signing\n\u003e sessions, same adaptor\" proved to be the most interesting: in trying to\n\u003e reduce this to ECDLP I found an issue around sequencing. It may just be\n\u003e irrelevant but I'd be curious to hear what others think about that.\n\u003e\n\u003e If nothing else, I'd be very interested to hear what experts in the field\n\u003e have to say about security reductions for this primitive in the case of\n\u003e multiple concurrent signing sessions (which of course has been analyzed\n\u003e very carefully already for base MuSig(2)).\n\u003e\n\u003e Cheers,\n\u003e AdamISZ/waxwing\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e Sent with Proton Mail secure email.\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/20230501/5c70f1ea/attachment.html\u003e",
"sig": "f2de95f264823b6c1fd3b5a5f3aa06f5985205aab9ee846d9162245a7bdcbc4eaa416354bbf6f256d6f89f7efdd7b24557b8798f9786633d208880819a4d8f4b"
}