From: Jonas Nick <jonasd.nick@gmail•com>
To: bitcoindev@googlegroups.com
Subject: Re: [bitcoindev] Re: DahLIAS: Discrete Logarithm-Based Interactive Aggregate Signatures
Date: Tue, 22 Apr 2025 15:29:04 +0000 [thread overview]
Message-ID: <2ede88e8-2570-442f-a073-730f7de70eca@gmail.com> (raw)
In-Reply-To: <242c6fdd-f629-4a2a-900c-7b1d770eedbbn@googlegroups.com>
Thanks for bringing this up. It's an interesting question and it made us realize
that we should clarify this section of the paper, as there are indeed some
subtleties here that are currently unmentioned.
> I don't understand why this same attack cannot be applied to MuSig2 itself?
There are nuances, but I think it's fair to say that the same attack cannot be
applied to MuSig2 itself. During the attack, the adversary requests a partial
signature for public key X and message m from the honest signer. Using this, the
adversary is able to create a partial signature for public key X' = TweakPK(X,
t), where t is some tweak chosen by the adversary, and message m'. When applying
the attack to MuSig2, we have that m' = m, and when applying it to MuSig2-IAS,
we may have m != m'.
So, using the attack, the adversary is able to produce a signature sigma_1 for
MuSig2 and sigma_2 for MuSig2-IAS such that
- MuSig2.Verify(KeyAgg(X, X'), m, sigma_1) = 1, and
- MuSig2-IAS.Verify((X, m), (X', m'), sigma_2) = 1.
sigma_2 is clearly a forgery under the EUF-CMA-TK security model defined in the
DahLIAS paper because it is a signature for a message m' that the honest signer
hasn't signed. In contrast, sigma_1 only covers the message that the honest
signer actually signed. Whether sigma_1 counts as a forgery depends on the
abstract security notion that you consider for multisignature tweaking. We
didn't provide such a model in the MuSig2 paper and I am not aware of a standard
one. It would be easy to design a security model where sigma_1 constitutes a
forgery and one where it doesn't.
More importantly, could this be a problem for MuSig2 in practice? I can only
come up with contrived scenarios, but it may still be worth mentioning in the
BIP, for example.
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/2ede88e8-2570-442f-a073-730f7de70eca%40gmail.com.
prev parent reply other threads:[~2025-04-22 17:02 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-17 16:27 [bitcoindev] " Jonas Nick
2025-04-19 16:28 ` [bitcoindev] " waxwing/ AdamISZ
2025-04-22 15:29 ` Jonas Nick [this message]
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=2ede88e8-2570-442f-a073-730f7de70eca@gmail.com \
--to=jonasd.nick@gmail$(echo .)com \
--cc=bitcoindev@googlegroups.com \
/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