[bitcoin-dev] Multiparty signatures

Erik Aronesty erik at q32.com
Mon Jul 9 17:59:23 UTC 2018


 - 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 at xiph.org> wrote:

> On Mon, Jul 9, 2018 at 4:33 PM, Erik Aronesty <erik at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180709/5b9f7929/attachment.html>


More information about the bitcoin-dev mailing list