From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 4AD3EC013A for ; Thu, 11 Feb 2021 14:39:09 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by fraxinus.osuosl.org (Postfix) with ESMTP id 0981980CD8 for ; Thu, 11 Feb 2021 14:39:09 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from fraxinus.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oVIi_8KvnsPQ for ; Thu, 11 Feb 2021 14:39:07 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40134.protonmail.ch (mail-40134.protonmail.ch [185.70.40.134]) by fraxinus.osuosl.org (Postfix) with ESMTPS id B7BDD86E07 for ; Thu, 11 Feb 2021 14:39:06 +0000 (UTC) Date: Thu, 11 Feb 2021 14:38:57 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1613054343; bh=OgSNkbTYfnT6AqcG2Z93qAGTpybzn3AfyWvx2Urh1to=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=G6jlp6puro9VZPH53e1HUIe7lqfSyrrd3cOsiCWjdlMejAyLvEW8pj41Wtwf29Otu rgQAeqYlJSTFlI0Ad/sHYWLZefXZnqETU705gXGAeTAyNcwcsQnR8FlLHsw6we1NCr PxhoDE9tAuElgGyHtxP0syXX75c1BYHdTDq3ep3s= To: Pieter Wuille From: Dr Maxim Orlovsky Reply-To: Dr Maxim Orlovsky Message-ID: <5096768E-3A77-4CD8-AC22-105CA63152A7@protonmail.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 11 Feb 2021 14:40:10 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] BIP32/43-based standard for Schnorr signatures & decentralized identity X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2021 14:39:09 -0000 Hi Pieter, ... and sorry for misspelling your name in my first e-mail :( Thank you very much for all the clarifications; it=E2=80=99s good to have t= hem 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 sign= atures to avoid key reuse, am I right? Kind regards, Maxim > On Feb 6, 2021, at 02:15, Pieter Wuille wrote: >=20 >=20 > On Friday, February 5, 2021 9:51 AM, Dr Maxim Orlovsky via bitcoin-dev wrote: >=20 >> Hi, >>=20 >> Background >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> Had a discussion last night in Bitcoin Core IRC with Peter Wuille on dif= ferent topics regarding key derivations, security, key tweaks in context of= Schnorr signatures & Taproot. Would like to share some action points and p= lans that emerged from there: >>=20 >> 1. There is a real need for BIP-43 based new BIP with a new purpose fie= ld for keys used in Schnorr signatures. Peter will not do it (he is not ver= y much interested in spending his time on wallet-level stuff), so someone e= lse should. >> 2. Keys used in Schnorr signatures MUST NEVER BE used in ECDSA signatur= es, otherwise there is a risk of private key leak via correlation attack. T= his is rationale behind N1. >=20 > Hi Maxim, >=20 > thanks for bringing up this discussion here. I'd like to clarify a few th= ings though, as I think the above is formulated far too strongly. >=20 > 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 cryptograp= hic reasons. And in practice, solutions to the first (which we already need= , unrelated to Taproot/Schnorr) mean the second is largely moot. >=20 >=20 > # Don't reuse keys for privacy/organizational reasons. >=20 > Reusing the same key in Bitcoin scripts - for use in distinct signature s= chemes or not - should always be avoided. It has obvious privacy implicatio= ns; I don't think this is controversial, and it's a problem that exists tod= ay, unrelated to Taproot. E.g. you don't want to reuse the same keys as bot= h single-sig and participation in multisig. >=20 > My personal view here is that distinct standard derivation paths help wit= h this in the simple cases, but they're not a full solution in the most gen= eral 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 eac= h anyway. For this reason in general I prefer solutions that explicitly tra= ck what path is used for what. >=20 >=20 > # Don't use related keys for cryptographic reasons >=20 > There are some concerns to address here, but I want to make it clear ther= e are no known attacks against usage of related keys across ECDSA and Schno= rr, and I don't expect there will be. However, there is probably no proof f= or this, and creating one may be tricky. On the other hand, the ecosystem (= Bitcoin, but also many other applications) has accepted ECDSA long ago, whi= le it had no security proofs whatsoever (and even the ones that exist now r= ely on fairly unusual assumption; a proof for security of mixed Schnorr/ECD= SA usage would inherently need equally unusual assumptions too). >=20 > Now, as soon as a hardened derivation separates different uses there is n= o concern at all. So any solution for avoiding key reuse (section above) th= at works by assigning (implicitly or explicitly) different hardened derivat= ion paths (as BIP43 etc. do) to different uses implies there is never any c= oncern about related keys across Schnorr/ECDSA. >=20 > If the keys are not separated by a hardened step, it's more complicated. = Looking at the different cases: >=20 > (1) Signing with related ECDSA keys (e.g. two unhardened child keys from = the same xpub) >=20 > - This is very common on BIP32 usage today, so hopefully it is secure! Ti= m 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 actual= ly secure, but I don't know under what assumptions. Note that the comment t= here about Schnorr not having this property does not apply to BIP340, becau= se it uses key-prefixed Schnorr. >=20 > (2) Signing with related Schnorr keys. >=20 > - 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 an= ything about others. A formal proof is probably a bit longer, but still tri= vial to construct. >=20 > (3) The real question: signing with a Schnorr key that is related to an E= CDSA key. >=20 > - 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 ha= shes. Aspects such as BIP340's key prefixing and the fact that Bitcoin sigh= ashes indirectly commit to the (set of) signing pubkeys make it even harder= . >=20 >=20 > # TL;DR >=20 > * For privacy reasons, you should use separate keys/derivation branches f= or different uses in all circumstances (duh). > * To stay within the realm of provably security it's advisable to make su= re 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 th= ink most people aren't even aware of). >=20 > Cheers, >=20 > -- > Pieter