public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
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: Mon, 9 Jul 2018 13:59:23 -0400	[thread overview]
Message-ID: <CAJowKgL0b3RT7XwRTF+ohoJCyZAW-ZJ+-8Lijj_s1rqqxgU7VQ@mail.gmail.com> (raw)
In-Reply-To: <CAAS2fgRrkzq6Fa5T_-YDwLDkwi30LpDtMObMEBE+Fmmj0LJpBw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2450 bytes --]

 - 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: 8749 bytes --]

  reply	other threads:[~2018-07-09 17:59 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 [this message]
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
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=CAJowKgL0b3RT7XwRTF+ohoJCyZAW-ZJ+-8Lijj_s1rqqxgU7VQ@mail.gmail.com \
    --to=erik@q32.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=greg@xiph.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