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
[bitcoin-dev] Taproot activation meeting 2 - Tuesday 16th February 19:00 UTC
A summary of the first Taproot activation meeting (February 3rd) is here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018379.html It appears there is one (hopefully) last stumbling block before we are ready to propose Taproot activation parameters to the mailing list. Hence we are organizing a follow up meeting on IRC on the ##taproot-activation channel on Tuesday 16th February at 19:00 UTC. As I said in the summary of the first Taproot activation meeting whether lockinontimeout (LOT) is set to true or false in a Bitcoin Core release attracted discussion during the meeting and has continued to attract discussion afterwards. I will weigh up the arguments I have seen for both true and false here. I won’t comment on the strength of the arguments, merely attempt to summarize them. Any errors are my own. Arguments for setting lockinontimeout (LOT) to true in a Core release T1) This entirely eradicates the possibility (however unlikely) that Taproot fails to activate within a year. Although approximately 90 percent of mining pools have already pledged to activate Taproot there is no reason to open the door to possible delays and political shenanigans for no reason, however unlikely. T2) Given users can change LOT=true at any point (and some have declared they will be setting LOT=true regardless), setting LOT=false in Core opens up edge case scenarios where different proportions of users on the network change to LOT=true at different points in time in an uncoordinated fashion. Given the end state we all want is Taproot activated it doesn’t make sense to open the door to these edge cases. Setting LOT=true in Core would mean there is no motivation for users to change LOT in the software they are running. T3) We should not be putting users in a place where they feel they need to change LOT. The urge to change LOT will be strong if miners delay for an unreasonable period. We are then in a situation where a decision has to be made on whether Core releases a new version with LOT=true and this whole discussion kicks off again. We should definitely seek to avoid the need to rehash this discussion later in the year. T4) LOT is only relevant if miners fail to activate. It doesn’t make sense to set it to false as that is essentially saying if miners fail to activate early, LOT should also let them not activate. T5) Activation should only be attempted once community consensus for the soft fork has been reached. Miner signaling is not voting for the changes, it is signaling readiness. There is no reasonable rationale for not being ready within a year. T6) An argument belcher outlined on IRC. If LOT was set to true and a chain split happened then the Taproot chain doesn’t have wipeout risk so there’s a really strong incentive to be on the Taproot activating LOT=true chain and therefore using LOT=true means the risk of a chain split is actually lower. Arguments for setting lockinontimeout (LOT) to false in a Core release F1) The probability of Taproot not being activated by miners is small. This is not 2017, this is not SegWit, there is no need to worry. F2) The worst case scenario is we have to wait over a year for Taproot to be activated. Even the worst case scenario is not a disaster. F3) If in the unlikely scenario miners did not activate Taproot for a year for no apparent reason we would never set LOT to false again for any potential future soft fork. If miners fail to activate Taproot despite pledging support and there being overwhelming community consensus for it, it would set a precedent that miners cannot be relied upon *at all* to activate soft forks. F4) If in the highly unlikely scenario that a bug or some problem with the Taproot implementation was found during the signaling period miners could choose not to activate it which is cleaner than needing an emergency Core release. Then some additional arguments nullc posted on Reddit https://old.reddit.com/r/Bitcoin/comments/lcjhl6/taproot_activation_pools_will_be_able_to_veto/gm2l02w/ F5) LOT = false is more similar to what was done previously (unless you go way back to the earliest soft forks which were more similar to LOT = true) F6) It is more important that no rules that harm users are deployed than it is that new useful rules are deployed quickly. If there is a choice between “faster” and “more clear that this isn’t a mechanism to force bad things on users” we should prefer the latter. Plenty of people just don’t like LOT=true very much absent evidence that miners are blocking deployment. To some it just feels needlessly antagonistic and distrusting towards part of our community. There are some additional parameters other than LOT we will discuss in this meeting such as activation threshold, start time etc but personally I don’t think they will attract the same discussion as LOT. As I’ve stated before please continue to engage productively and in good faith. I can see arguments with merit on both sides of
