Re: [bitcoin-dev] BIP32/43-based standard for Schnorr signatures & decentralized identity
Hi Pieter, Addressing your comments: >> 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. Yes, previously we had a dedicated standards (BIPs) for purpose fields on each variant: single-sig, multi-sig etc. With this proposal I simplify this: you will have a dedicated deterministically-derived *hardened* keys for each use case under single standard, which should simplify future wallet implementations. > 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. In the BIP proposal there is a part on how multisigs can be created in a simple and deterministic way without keys reuse. > 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. My proposal is to have a new purpose field supporting all the above: hardened derivation that supports for multisigs, single-sigs etc. Kind regards, Maxim ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP32/43-based standard for Schnorr signatures & decentralized identity
Hi Adam, Commenting on your question: > With segWit vs pre-SegWit didn't wallets just select and standardize > on a different HD derivation path? > > Is there something else needed than a Schnorr derivation path? The general accepted practice (defined in BIP43) is to define a dedicated purpose field for each kind of key derivation and address encoding. There is a dedicated purpose for pre-SegWit, SegWit, multisigs — and now a purpose for Schnorr sigs/Taproot outputs is needed. That is why I brought forward this proposal, which addresses exactly this need - and also will support at the same time multisigs and pre-Taproot outputs, making all previously used purpose fields redundant, simplifying future wallets. Kind regards, Maxim ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP32/43-based standard for Schnorr signatures & decentralized identity
‐‐‐ Original Message ‐‐‐ On Thursday, February 11, 2021 6:38 AM, Dr Maxim Orlovsky 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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP32/43-based standard for Schnorr signatures & decentralized identity
Hi Pieter, ... and sorry for misspelling your name in my first e-mail :( 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? Kind regards, Maxim > On Feb 6, 2021, at 02:15, Pieter Wuille wrote: > > > On Friday, February 5, 2021 9:51 AM, Dr Maxim Orlovsky via bitcoin-dev > wrote: > >> Hi, >> >> Background >> >> >> >> Had a discussion last night in Bitcoin Core IRC with Peter Wuille on >> different topics regarding key derivations, security, key tweaks in context >> of Schnorr signatures & Taproot. Would like to share some action points and >> plans that emerged from there: >> >> 1. There is a real need for BIP-43 based new BIP with a new purpose field >> for keys used in Schnorr signatures. Peter will not do it (he is not very >> much interested in spending his time on wallet-level stuff), so someone else >> should. >> 2. Keys used in Schnorr signatures MUST NEVER BE used in ECDSA signatures, >> otherwise there is a risk of private key leak via correlation attack. This >> is rationale behind N1. > > Hi Maxim, > > thanks for bringing up this discussion here. I'd like to clarify a few things > though, as I think the above is formulated far too strongly. > > There are two issues here: (1) reasons to avoid reusing the same key for > privacy reasons, and (2) reasons to avoid using related keys for > cryptographic reasons. And in practice, solutions to the first (which we > already need, unrelated to Taproot/Schnorr) mean the second is largely moot. > > > # Don't reuse keys for privacy/organizational reasons. > > Reusing the same key in Bitcoin scripts - for use in distinct signature > schemes or not - should always be avoided. It has obvious privacy > implications; I don't think this is controversial, and it's a problem that > exists today, unrelated to Taproot. E.g. you don't want to reuse the same > keys as both single-sig and participation in multisig. > > My personal view here is that distinct standard derivation paths help with > this in the simple cases, but they're not a full solution in the most general > case. E.g. if you want to use one seed/root to participate in multiple sets > of multisig policies, you'll need some kind of index to assign to each > anyway. For this reason in general I prefer solutions that explicitly track > what path is used for what. > > > # Don't use related keys for cryptographic reasons > > There are some concerns to address here, but I want to make it clear there > are no known attacks against usage of related keys across ECDSA and Schnorr, > and I don't expect there will be. However, there is probably no proof for > this, and creating one may be tricky. On the other hand, the ecosystem > (Bitcoin, but also many other applications) has accepted ECDSA long ago, > while it had no security proofs whatsoever (and even the ones that exist now > rely on fairly unusual assumption; a proof for security of mixed > Schnorr/ECDSA usage would inherently need equally unusual assumptions too). > > Now, as soon as a hardened derivation separates different uses there is no > concern at all. So any solution for avoiding key reuse (section above) that > works by assigning (implicitly or explicitly) different hardened derivation > paths (as BIP43 etc. do) to different uses implies there is never any concern > about related keys across Schnorr/ECDSA. > > If the keys are not separated by a hardened step, it's more complicated. > Looking at the different cases: > > (1) Signing with related ECDSA keys (e.g. two unhardened child keys from the > same xpub) > > - This is very common on BIP32 usage today, so hopefully it is secure! Tim > Ruffing pointed me today to > https://link.springer.com/chapter/10.1007/978-3-030-36938-5_8 whose abstract > seems to indicate they prove this is actually secure, but I don't know under > what assumptions. Note that the comment there about Schnorr not having this > property does not apply to BIP340, because it uses key-prefixed Schnorr. > > (2) Signing with related Schnorr keys. > > - I believe this is secure simply because BIP340 challenges commit to the > pubkey (key prefixing), and thus a signature on one shouldn't teach you > anything about others. A formal proof is probably a bit longer, but still > trivial to construct. > > (3) The real question: signing with a Schnorr key that is related to an ECDSA > key. > > - I don't expect that this is easy to prove, but I have a very hard time > imagining how it could be exploitable, given the use of domain-separated > hashes. Aspects such as BIP340's key prefixing and the fact that Bitcoin > sighashes indirectly commit to the (set of) signing pubkeys make it even > harder. > > > # TL;DR > > * For privacy reasons, you
Re: [bitcoin-dev] BIP32/43-based standard for Schnorr signatures & decentralized identity
Hi Christopher, Thank you very much! Will look forward to talk to you regarding all of these, as we discussed elsewhere. Kind regard, Maxim > On Feb 5, 2021, at 23:37, Christopher Allen > wrote: > > Concept ACK. > > I, in my role as a co-author of the emerging W3C Decentralized Identifier > standard and of the BTCR DID method, organizer of the Bitcoin Airgapped > Wallet Community > (https://github.com/blockchainCommons/airgapped-Wallet-Community/discussions), > and as principal architect of Blockchain Commons, am very interested in > supporting discussion on this topic, and implementation of anything we > decide. I also have some Patron's to Blockchain Commons interested in this > topic and may be willing to financially support some reference code. > > -- Christopher Allen ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP32/43-based standard for Schnorr signatures & decentralized identity
Hi Dmitry, Thank you very much for readying and analyzing my proposal! >> Testnet path is unhardened from this point & till the end of the >> derivation path: no need to prevent private key leak there, >> simplifies test software (hardened paths require private key access >> for derivation). > > I believe this will reduce robustness and will add complexity to the > test software instead. If the derivation path is hardened in 'production > code' and is unhardened in 'test code', then: code paths that depend on > hardened derivation may not be tested; there will be unnecessary > code that will need to deal with 'un-hardening' the paths for test code. <...> > It is OK to require privkey access to hardened paths in test > software, because the same behaviour is expected in 'production’. You are right, agree > It is much more robust to just change the 'purpose' part of the path, > and leave the rest unchanged. Not sure whether the purpose is the correct place to indicate testnet: in this case it we will have to support one testnet per each blockchain type (which is not the case). So probably we should reserve a single dedicated value for any testnet withing ``blockchain` field using hardened path as you suggested - for instance, 0x may do the job. Kind regards, Maxim ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP32/43-based standard for Schnorr signatures & decentralized identity
On Friday, February 5, 2021 9:51 AM, Dr Maxim Orlovsky via bitcoin-dev wrote: > Hi, > > Background > > > > Had a discussion last night in Bitcoin Core IRC with Peter Wuille on > different topics regarding key derivations, security, key tweaks in context > of Schnorr signatures & Taproot. Would like to share some action points and > plans that emerged from there: > > 1. There is a real need for BIP-43 based new BIP with a new purpose field > for keys used in Schnorr signatures. Peter will not do it (he is not very > much interested in spending his time on wallet-level stuff), so someone else > should. > 2. Keys used in Schnorr signatures MUST NEVER BE used in ECDSA signatures, > otherwise there is a risk of private key leak via correlation attack. This is > rationale behind N1. Hi Maxim, thanks for bringing up this discussion here. I'd like to clarify a few things though, as I think the above is formulated far too strongly. There are two issues here: (1) reasons to avoid reusing the same key for privacy reasons, and (2) reasons to avoid using related keys for cryptographic reasons. And in practice, solutions to the first (which we already need, unrelated to Taproot/Schnorr) mean the second is largely moot. # Don't reuse keys for privacy/organizational reasons. Reusing the same key in Bitcoin scripts - for use in distinct signature schemes or not - should always be avoided. It has obvious privacy implications; I don't think this is controversial, and it's a problem that exists today, unrelated to Taproot. E.g. you don't want to reuse the same keys as both single-sig and participation in multisig. My personal view here is that distinct standard derivation paths help with this in the simple cases, but they're not a full solution in the most general case. E.g. if you want to use one seed/root to participate in multiple sets of multisig policies, you'll need some kind of index to assign to each anyway. For this reason in general I prefer solutions that explicitly track what path is used for what. # Don't use related keys for cryptographic reasons There are some concerns to address here, but I want to make it clear there are no known attacks against usage of related keys across ECDSA and Schnorr, and I don't expect there will be. However, there is probably no proof for this, and creating one may be tricky. On the other hand, the ecosystem (Bitcoin, but also many other applications) has accepted ECDSA long ago, while it had no security proofs whatsoever (and even the ones that exist now rely on fairly unusual assumption; a proof for security of mixed Schnorr/ECDSA usage would inherently need equally unusual assumptions too). Now, as soon as a hardened derivation separates different uses there is no concern at all. So any solution for avoiding key reuse (section above) that works by assigning (implicitly or explicitly) different hardened derivation paths (as BIP43 etc. do) to different uses implies there is never any concern about related keys across Schnorr/ECDSA. If the keys are not separated by a hardened step, it's more complicated. Looking at the different cases: (1) Signing with related ECDSA keys (e.g. two unhardened child keys from the same xpub) - This is very common on BIP32 usage today, so hopefully it is secure! Tim Ruffing pointed me today to https://link.springer.com/chapter/10.1007/978-3-030-36938-5_8 whose abstract seems to indicate they prove this is actually secure, but I don't know under what assumptions. Note that the comment there about Schnorr not having this property does not apply to BIP340, because it uses key-prefixed Schnorr. (2) Signing with related Schnorr keys. - I believe this is secure simply because BIP340 challenges commit to the pubkey (key prefixing), and thus a signature on one shouldn't teach you anything about others. A formal proof is probably a bit longer, but still trivial to construct. (3) The real question: signing with a Schnorr key that is related to an ECDSA key. - I don't expect that this is easy to prove, but I have a very hard time imagining how it could be exploitable, given the use of domain-separated hashes. Aspects such as BIP340's key prefixing and the fact that Bitcoin sighashes indirectly commit to the (set of) signing pubkeys make it even harder. # TL;DR * For privacy reasons, you should use separate keys/derivation branches for different uses in all circumstances (duh). * To stay within the realm of provably security it's advisable to make sure ECDSA key and Schnorr keys use distinct hardened derivation steps. * Even if you don't, you're really just back to the level of assurance we had about unhardened BIP32 ECDSA keys before a proof was known (which I think most people aren't even aware of). Cheers, -- Pieter ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org
Re: [bitcoin-dev] BIP32/43-based standard for Schnorr signatures & decentralized identity
Concept ACK. I, in my role as a co-author of the emerging W3C Decentralized Identifier standard and of the BTCR DID method, organizer of the Bitcoin Airgapped Wallet Community ( https://github.com/blockchainCommons/airgapped-Wallet-Community/discussions), and as principal architect of Blockchain Commons, am very interested in supporting discussion on this topic, and implementation of anything we decide. I also have some Patron's to Blockchain Commons interested in this topic and may be willing to financially support some reference code. -- Christopher Allen ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP32/43-based standard for Schnorr signatures & decentralized identity
В Fri, 05 Feb 2021 17:51:27 + Dr Maxim Orlovsky via bitcoin-dev wrote: > Testnet path is unhardened from this point & till the end of the > derivation path: no need to prevent private key leak there, > simplifies test software (hardened paths require private key access > for derivation). I believe this will reduce robustness and will add complexity to the test software instead. If the derivation path is hardened in 'production code' and is unhardened in 'test code', then: code paths that depend on hardened derivation may not be tested; there will be unnecessary code that will need to deal with 'un-hardening' the paths for test code. It is much more robust to just change the 'purpose' part of the path, and leave the rest unchanged. It is OK to require privkey access to hardened paths in test software, because the same behaviour is expected in 'production'. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] BIP32/43-based standard for Schnorr signatures & decentralized identity
Hi, Background == Had a discussion last night in Bitcoin Core IRC with Peter Wuille on different topics regarding key derivations, security, key tweaks in context of Schnorr signatures & Taproot. Would like to share some action points and plans that emerged from there: 1. There is a real need for BIP-43 based new BIP with a new purpose field for keys used in Schnorr signatures. Peter will not do it (he is not very much interested in spending his time on wallet-level stuff), so someone else should. 2. Keys used in Schnorr signatures MUST NEVER BE used in ECDSA signatures, otherwise there is a risk of private key leak via correlation attack. This is rationale behind N1. 3. The other need (not discussed with Peter) is to change the general structure of derivation path used before with BIP-44, 45, 84. This change is required to enable the use of all modern wallet use cases under a single standard: single-sigs & multi-sigs, ECDSA & BIP340 signatures. 4. Embedding multisig support in a hierarchical format requires introduction of a “signer id” concept as a part of the derivation path. I found a way how this can be done seamlessly, leading to emergence of decentralized identity as a side effect. Proposal Derivation path structure & purpose values -- The new format for the hierarchical derivation BIP32 path is the following: m/purpose’/blockchain’/identity’/scope'/case/index **Purpose:** BIP-43 purpose values under the proposal: - 340’ for BIP340 signatures - ???’ for old-style ECDSA signatures (??? will be set to the BIP number of this standard once it gets assigned) Thus, purpose will be used to signify the type of the signature. NB: purpose MUST be hardened since otherwise a key leak may occur. **Blockchain:** was not there before, but now we should have it: - to prevent key reuse across blockchains & combined inter-chain analysis - to get rid of using custom xpub prefixes (like SLIP-132) which are very unwelcomed by the community and are unnecessary since we have descriptors. Testnet path `1` covers all testnets (no problem with key re-use for valueless testnet or inter-testnet chainanalysis) - this follows the logic of recent changes in other standards related to testnet (use the same Bech32 prefixes for all testnets). Testnet path is unhardened from this point & till the end of the derivation path: no need to prevent private key leak there, simplifies test software (hardened paths require private key access for derivation). Devs are free to choose other unhardened number if they need, without changing the standard - unhardened numbers will never be used for chains with real value. **Identity and scope** Hardened components signify the main identity (decentralized id) and the scope under that id used in context of specific multisig wallet or other identity case. Scope is required to use the same id with different peers without exposing the main identity xpub (and, thus, the scope must be hardened as well). **Case** This is the same as a “change” field before (under BIP44 etc), however it is proposed to change the name to denote that the field may have other values and is used for signalling support for some custom features (for instance, pay-to-contract or sign-to-contract schemes, which may be used for client-side validation like in RGB protocol etc). **Index** Sequentially increased index like in BIP44 Identity basics --- **Identity index** SHOULD be a random number within BIP32 hardened index range. Rationale: derivation path may be kept public (see decentralized logins below), and use of sequential numbers will leak information of how many identities are used by some person. **(Identity) scope index**: depending on whether revocation is enabled: - if revocation is not enabled, or before the first revocation, it SHOULD be any random hardened number - otherwise, it must be a number provided during the revocation procedure for the previous scope Rationale for identity scope: it is required for an identity to be safely usable under multiple multisig wallets/descriptors without exposure of the identity xpub to unrelated parties. Its introduction also allows to use the keys derived under the same identity index as a universal decentralized identity (see details below) without the risk of correlation analyses; especially when they are used outside of the transaction context (for instance as a part of login) without the risk of chain analysis against such data (linking logins to onchain transactions). Identity representations The XpubIdentifier created with extended public key under BIP32 derivation path ending at the level of the identity index is called **bitcoin decentralized id** (hereinafter simply **decentralized id**). Rationale: XpubIdentifier is a hash of the extended public key, thus id does not leak any confidential information
