From: Erik Aronesty <erik@q32.com>
To: adam@cypherspace.org
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Multiparty signatures
Date: Thu, 19 Jul 2018 08:16:04 -0400 [thread overview]
Message-ID: <CAJowKg+QxcU0ECpZrvUckXQfBpn6Qri=gWzLA7+Y2mvTAq_mSw@mail.gmail.com> (raw)
In-Reply-To: <CAJowKg+rC9rmv--NxtrFQ=ea4B20u0ozkmA5hARpA4wLinnVQg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2302 bytes --]
Also Wagner's algorithm shouldn't be applicable for a number of reasons.
you can't birthday attack something where there's only a single variable
that you can modify. And when you change the equation from additive you
now have a multi-dimensional equation we're partitioning won't function.
this is the basis of the perfect security of Shamir secret sharing.
On Wed, Jul 11, 2018, 10:45 AM Erik Aronesty <erik@q32.com> wrote:
> OK, so you're going with this scenario:
>
> 1. I know Apub and Bpub,
> 2. I know M is 3
> 3. I'm choosing a random number for C's private key
>
> Cpub is g^C
>
> The equation I am solving for .. and trying to factor myself out of is
> g^Ax + g^B*2 + g^C*3
>
> I don't know A or B... I only know their public keys.
>
> I don't think it's possible to adaptively choose C for an attack on the
> multisig construction, when using hash of the public key as the X
> coordinate in the polynomial, because in order to satisfy the equation and
> factor out C, you would need to be able to break the hash.
>
> With an additive construction, yes... adaptive attacks are possible. But
> in a shamir secret sharing interpolation, you need a public X coordinate as
> well as a secret share. Choosing hash(pub) as X, prevents this attack.
>
>
> On Wed, Jul 11, 2018 at 6:35 AM, Adam Back <adam.back@gmail.com> wrote:
>
>> On Wed, Jul 11, 2018, 02:42 Erik Aronesty via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>> > Basically you're just replacing addition with interpolation everywhere
>> in the musig construction
>>
>> Yes, but you can't do that without a delinearization mechanism to prevent
>> adaptive public key choice being used to break the scheme using Wagner's
>> attack. It is not specific to addition, it is a generalized birthday attack.
>>
>> Look at the delinearization mechanism for an intuition, all public keys
>> are hashed along with per value hash, so that pre-commits and forces the
>> public keys to be non-adaptively chosen.
>>
>> Adaptively chosen public keys are dangerous and simple to exploit for
>> example pub keys A+B, add party C' he chooses C=C'-A-B, now we can sign for
>> A+B+C using adaptively chose public key C.
>>
>> Btw Wagner also breaks this earlier delinearization scheme
>> S=H(A)*A+H(B)*B+H(C)*C
>>
>> Adam
>>
>
>
[-- Attachment #2: Type: text/html, Size: 3551 bytes --]
next prev parent reply other threads:[~2018-07-19 12:16 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-08 14:19 [bitcoin-dev] Multiparty signatures Erik Aronesty
2018-07-08 15:16 ` Tim Ruffing
2018-07-08 18:23 ` Erik Aronesty
2018-07-08 21:01 ` Gregory Maxwell
2018-07-09 0:27 ` Erik Aronesty
2018-07-09 2:33 ` Pieter Wuille
2018-07-09 4:29 ` Erik Aronesty
2018-07-09 4:39 ` Pieter Wuille
[not found] ` <CAJowKg+=7nS4gNmtc8a4-2cu1uCOPqxjfchFwDVqUciKNMUYWQ@mail.gmail.com>
2018-07-09 15:02 ` Erik Aronesty
2018-07-09 15:57 ` Dan Robinson
2018-07-09 15:59 ` Gregory Maxwell
2018-07-09 16:33 ` Erik Aronesty
2018-07-09 16:58 ` Gregory Maxwell
2018-07-09 17:59 ` Erik Aronesty
2018-07-10 11:46 ` Erik Aronesty
2018-07-11 10:35 ` Adam Back
2018-07-11 14:45 ` Erik Aronesty
2018-07-19 12:16 ` Erik Aronesty [this message]
2018-07-19 12:24 ` Erik Aronesty
2018-07-19 13:11 ` Russell O'Connor
2018-07-20 16:25 ` Erik Aronesty
2018-07-20 17:34 ` Erik Aronesty
2018-07-20 20:18 ` Erik Aronesty
2018-07-26 2:05 ` Erik Aronesty
2018-07-09 16:21 ` Gregory Maxwell
2018-07-09 2:29 ` Pieter Wuille
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='CAJowKg+QxcU0ECpZrvUckXQfBpn6Qri=gWzLA7+Y2mvTAq_mSw@mail.gmail.com' \
--to=erik@q32.com \
--cc=adam@cypherspace.org \
--cc=bitcoin-dev@lists.linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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