public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: AdamISZ <AdamISZ@protonmail•com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: [bitcoin-dev] On adaptor security (in protocols)
Date: Fri, 28 Apr 2023 18:13:03 +0000	[thread overview]
Message-ID: <Vv-Zz519CQs1JkS8NgeHfI-KGaYelNTxKMikPxdeIRiELmPKlT80g_-BzDgBvpm9MMIr-BRrSyGePC-HFR18QU4uzC0rPJdMzO_hlkUhUaM=@protonmail.com> (raw)

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.


             reply	other threads:[~2023-04-28 18:13 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-28 18:13 AdamISZ [this message]
2023-05-01  4:23 ` Lloyd Fournier
2023-05-01 18:37   ` AdamISZ
2023-05-03 12:58     ` AdamISZ
2023-05-08  4:37     ` Lloyd Fournier
2023-05-11  5:12       ` AdamISZ
2023-05-11 11:41         ` Lloyd Fournier
2023-05-14  8:37           ` AdamISZ

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='Vv-Zz519CQs1JkS8NgeHfI-KGaYelNTxKMikPxdeIRiELmPKlT80g_-BzDgBvpm9MMIr-BRrSyGePC-HFR18QU4uzC0rPJdMzO_hlkUhUaM=@protonmail.com' \
    --to=adamisz@protonmail$(echo .)com \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox