From: Jonas Nick <jonasdnick@gmail•com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] MuSig2 BIP
Date: Tue, 11 Oct 2022 15:34:23 +0000 [thread overview]
Message-ID: <576db60c-b05b-5b9a-75e5-9610f3e04eda@gmail.com> (raw)
In-Reply-To: <6d823ec7-fe88-9311-09e8-be22ca8bfd89@gmail.com>
It is still true that cryptography is hard, unfortunately. Yannick Seurin, Tim
Ruffing, Elliott Jin, and I discovered an attack against the latest version of
BIP MuSig2 in the case that a signer's individual key A = a*G is tweaked before
giving it as input to key aggregation.
In more detail, a signer may be vulnerable if _all_ of the following conditions
are true:
1. The signer supports signing with a tweaked individual key (as provided to
key aggregation) and the tweak is known to the attacker (e.g., as in BIP 32
unhardened derivation).
2. The signer's public key appears at least two times with different tweaks in
the set of public keys that are aggregated. This would, for example, be the
case if a signer with public key A=a*G creates partial signatures for an
aggregate key corresponding to public key set {A, A+t*G} where t is some
tweak. Note that an attacker could make this condition true by using the key
B = A+t*G after having seen A.
3. The signer uses "concurrent signing", i.e., the signer stores secnonces for
multiple signing sessions.
4. The secret key provided to the Sign algorithm is not yet fully determined when the
NonceGen algorithm is called. This would, for example, be the case if the
attacker, after having seen the nonce of the signer, can influence whether a
or a+t will be provided as a secret key to Sign.
In this scenario, an attacker may forge a signature for any message and any
aggregate public key that contains the signer's individual public key A (with
any attacker-chosen tweak). In particular, the attacker may forge a signature
for any message and the public key A itself.
Condition 4 should only apply in relatively rare cases unless the signer is
tricked into such a situation.
Fix:
Note that if the optional secret key argument is provided to the NonceGen
algorithm and matches the secret key provided to the Sign algorithm, then
Condition 4 will not hold. Thus, one definite fix is to make the secret key
argument to the NonceGen algorithm mandatory. We are investigating other options
and will follow up shortly with a concrete fix of the BIP draft.
This discovery does not invalidate the security proof of the scheme as presented
in the MuSig2 paper because the security model in the paper does not support
tweaking a signer's key.
If you've implemented the BIP draft in your library or are already using it in
production don't hesitate to reach out to clarify the implications of this
discovery.
Tim Ruffing, Elliott Jin, Jonas Nick
next prev parent reply other threads:[~2022-10-11 15:34 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-05 22:57 Jonas Nick
2022-04-28 1:47 ` Olaoluwa Osuntokun
2022-04-28 3:53 ` Olaoluwa Osuntokun
2022-04-28 19:18 ` Jonas Nick
2022-05-22 22:26 ` AdamISZ
2022-05-23 15:56 ` Jonas Nick
2022-05-23 22:09 ` AdamISZ
2022-05-24 19:06 ` AdamISZ
2022-05-26 15:32 ` Jonas Nick
2022-05-26 17:34 ` AdamISZ
2022-06-12 23:07 ` AdamISZ
2022-10-03 20:41 ` Jonas Nick
2022-10-11 15:34 ` Jonas Nick [this message]
2022-11-03 14:43 ` Jonas Nick
2022-04-28 15:33 Brandon Black
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=576db60c-b05b-5b9a-75e5-9610f3e04eda@gmail.com \
--to=jonasdnick@gmail$(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