From: Pieter Wuille <bitcoin-dev@wuille•net>
To: Dr Maxim Orlovsky <orlovsky@protonmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP32/43-based standard for Schnorr signatures & decentralized identity
Date: Thu, 11 Feb 2021 20:31:13 +0000 [thread overview]
Message-ID: <AzQAiClGFEDDux7hDtaD3As76nWOJELk9eck-_Ra4lDTwXQz2lYJEwRHjq9Gt65cA7AgKbidpNQlD-U6g5OKM-EaNvPbgva-ASzt-LcBDT8=@wuille.net> (raw)
In-Reply-To: <5096768E-3A77-4CD8-AC22-105CA63152A7@protonmail.com>
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Thursday, February 11, 2021 6:38 AM, Dr Maxim Orlovsky <orlovsky@protonmail•com> wrote:
> Thank you very much for all the clarifications; it’s good to have them sorted out and clearly structured. From what you wrote it follows that we still need to reserve a dedicated purpose (with new BIP) for BIP340 signatures to avoid key reuse, am I right?
Maybe, but it would be for a particular way of using keys (presumably: single-key pay-to-taproot), not just the signature scheme itself. If you go down this path you'll also want dedicated branches for multisig participation, and presumably several interesting new policies that become possible with Taproot.
The only thing ECDSA/Schnorr specific about this is that - if you want to maintain provable security - the keys used for ECDSA and BIP340 should be separated by a hardened step. It seems however that all approaches people actually use to prevent reuse do that already.
And as I said, dedicated branches only help for the simple case. For example, it doesn't address the more general problem of preventing reuse of keys in multiple distinct groups of multisig sets you participate in. If you want to solve that you need to keep track of index is for participating in what - and once you have something like that you don't need dedicated purpose based derivation at all anymore.
So I'm not sure I'd state it as us *needing* a dedicated purpose/branch for single-key P2TR (and probably many other useful ways of using taproot based spending policies...). But perhaps it's useful to have.
Greg Maxwell pointed out to me that there may be another reason to want non-reuse across ECDSA and BIP340 keys: if someone were to do all of these wrong:
* not follow BIP340 and re-use RFC6979 for BIP340 nonce generation
* reuse the same keys for both
* sign the same message with both
... you would actually leak your private key. This isn't a concern for Bitcoin transaction signing however, as the sighash (message) indirectly commits to BIP341 or not, and thus it'd be impossible to construct colliding messages. Still, it's a consideration to factor in.
Cheers,
--
Pieter
next prev parent reply other threads:[~2021-02-11 20:31 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-05 17:51 Dr Maxim Orlovsky
2021-02-05 22:00 ` Dmitry Petukhov
2021-02-11 7:27 ` Dr Maxim Orlovsky
2021-02-05 22:37 ` Christopher Allen
2021-02-11 7:28 ` Dr Maxim Orlovsky
2021-02-06 1:15 ` Pieter Wuille
2021-02-11 14:38 ` Dr Maxim Orlovsky
2021-02-11 20:31 ` Pieter Wuille [this message]
2021-02-18 18:58 ` Dr Maxim Orlovsky
[not found] ` <CALqxMTG1MG+PvLfSLRqsa_yHBQOdu7BOqBjm4_ShSsB3CNSCOA@mail.gmail.com>
2021-02-18 18:52 ` Dr Maxim Orlovsky
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='AzQAiClGFEDDux7hDtaD3As76nWOJELk9eck-_Ra4lDTwXQz2lYJEwRHjq9Gt65cA7AgKbidpNQlD-U6g5OKM-EaNvPbgva-ASzt-LcBDT8=@wuille.net' \
--to=bitcoin-dev@wuille$(echo .)net \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=orlovsky@protonmail$(echo .)com \
/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