- 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 <g...@xiph.org> wrote: > On Mon, Jul 9, 2018 at 4:33 PM, Erik Aronesty <e...@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. >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev