From: Erik Aronesty <erik@q32•com>
To: Tim Ruffing <crypto@timruffing•de>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Composable MuSig
Date: Mon, 24 Feb 2020 10:30:54 -0500 [thread overview]
Message-ID: <CAJowKgJSaDUGM-X7U-eaaCSCSr6x0s+Z5U=Tt3Bt4J1D7SSnnA@mail.gmail.com> (raw)
In-Reply-To: <30bdd65dc943f698c0970ca51bfb4dfb406ea7b8.camel@timruffing.de>
Basically just some mechanism for preventing repeated signings of the
same message, and using a "validity" time window so that the amount of
state you need to enquire about isn't unbounded.
The Drijvers, et al paper is specifically concerned with parallel and
aborted signings, where ksums can be used. In general, the more
variables that an attacker can control ,the more "k" lists they can
form, and the more likely they can find collisions.
If signers refused to sign "stale" messages, refused to sign in
parallel beyond a certain limit, and refused to sign the same message
twice, it should help reduce the attack surface.
On Mon, Feb 24, 2020 at 6:41 AM Tim Ruffing via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
>
> On Sun, 2020-02-23 at 02:27 -0500, Erik Aronesty via bitcoin-dev wrote:
> > > Thus, two-phase MuSig is potentially unsafe.
> > > https://eprint.iacr.org/2018/417.pdf describes the argument.
> >
> > One solution is to add a signature timeout to the message (say a
> > block height) .
> >
> > A participant refuses to sign if that time is too far in the future,
> > or is at all in the past, or if a message M is the same as any
> > previous message within that time window.
> >
> > Seems to resolve the attacks on 2 round musig.
>
> I don't understand this. Can you elaborate?
>
> Best,
> Tim
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
next prev parent reply other threads:[~2020-02-24 15:31 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-25 11:00 ZmnSCPxj
2019-11-29 5:50 ` Lloyd Fournier
2019-12-02 2:05 ` ZmnSCPxj
2019-12-02 3:30 ` Lloyd Fournier
2019-12-08 1:15 ` ZmnSCPxj
2019-12-08 6:10 ` Lloyd Fournier
2020-02-23 7:27 ` Erik Aronesty
2020-02-24 11:16 ` Tim Ruffing
2020-02-24 15:30 ` Erik Aronesty [this message]
2020-02-24 16:56 ` Tim Ruffing
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='CAJowKgJSaDUGM-X7U-eaaCSCSr6x0s+Z5U=Tt3Bt4J1D7SSnnA@mail.gmail.com' \
--to=erik@q32$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=crypto@timruffing$(echo .)de \
/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