From: Erik Aronesty <erik@q32•com>
To: Gregory Maxwell <greg@xiph•org>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Multiparty signatures
Date: Tue, 10 Jul 2018 07:46:17 -0400 [thread overview]
Message-ID: <CAJowKg+UaMsY_nL6SBfb20Ltki+LdhXOwwvG_mAsUq_ww3Tesg@mail.gmail.com> (raw)
In-Reply-To: <CAJowKgL0b3RT7XwRTF+ohoJCyZAW-ZJ+-8Lijj_s1rqqxgU7VQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2784 bytes --]
Basically you're just replacing addition with interpolation everywhere in
the musig construction.
But maybe I just don't understand how Wagner's algorithm is relevant here.
On Mon, Jul 9, 2018, 1:59 PM Erik Aronesty <erik@q32•com> wrote:
> - Adaptive r choice shouldn't be possible since r is derived from the
> original threshold prf and it's not possible for a party to have any
> adaptive impact on the value of r
> - I'm guess I don't see how an attacker can use adaptive key choice in
> this context either. Any modification of the key should be useless
> AH!
>
> I forgot to include some assumptions. The important part here is that
> each party only has a share of the private key and publishes a share of the
> public key.
>
> This hopefully should preclude any sort of adaptive key attack.
>
> From scratch:
>
> 1. Has a public g^x'
> 2. Computes and broadcasts g^k' ... where k' is a random number
> 3. Computes r = g^k using lagrange interpolation (see
> http://crypto.stanford.edu/~dabo/papers/homprf.pdf)
> 4. Computes H(r || M), as per standard schnorr
> 5. Computes s' = k' - xe , as per standard schnorr .. except k' is a
> "share"
> 6. Publish (s', e, g^x')
>
> Verification:
>
> With m of n share-signatures:
>
> 1. Interpolation on m of n s' shares to get s
> 2. Interpolation on m of n g^x' shares to get g^x
> 3. Standard schnorr verification
>
> The actual public key of the "set of signers" is interpolated.
>
>
>
> On Mon, Jul 9, 2018 at 12:58 PM, Gregory Maxwell <greg@xiph•org> wrote:
>
>> On Mon, Jul 9, 2018 at 4:33 PM, Erik Aronesty <erik@q32•com> wrote:
>> >>> with security assumptions that match the original Schnorr
>> construction more closely,
>> >> More closely than what?
>> > More closely than musig.
>>
>> Musig is instructions on using the original schnorr construction for
>> multiparty signing which is secure against participants adaptively
>> choosing their keys, which is something the naive scheme of just
>> interpolating keys and shares is vulnerable to. It works as
>> preprocessing on the keys, then you continue on with the naive
>> protocol. The verifier (e.g. network consensus rules) is the same.
>>
>> Now that you're back to using a cryptographic hash, I think what
>> you're suggesting is "use naive interpolation of schnorr signatures"
>> -- which you can do, including with the verifier proposed in the BIP,
>> but doing that alone is insecure against adaptive key choice (and
>> potentially adaptive R choice, depending on specifics which aren't
>> clear enough to me in your description). In particular, although it
>> seems surprising picking your interpolation locations with the hash of
>> each key isn't sufficient to prevent cancellation attacks due to the
>> remarkable power of wagner's algorithm.
>>
>
>
[-- Attachment #2: Type: text/html, Size: 9381 bytes --]
next prev parent reply other threads:[~2018-07-10 11:46 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-08 14:19 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 [this message]
2018-07-11 10:35 ` Adam Back
2018-07-11 14:45 ` Erik Aronesty
2018-07-19 12:16 ` Erik Aronesty
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+UaMsY_nL6SBfb20Ltki+LdhXOwwvG_mAsUq_ww3Tesg@mail.gmail.com \
--to=erik@q32$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=greg@xiph$(echo .)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