Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 61294C0001 for ; Mon, 22 Mar 2021 07:56:11 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 3AA50402C9 for ; Mon, 22 Mar 2021 07:56:11 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp4.osuosl.org (amavisd-new); dkim=pass (1024-bit key) header.d=gazeta.pl Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qry4GmEvLYpJ for ; Mon, 22 Mar 2021 07:56:09 +0000 (UTC) X-Greylist: delayed 00:05:01 by SQLgrey-1.8.0 Received: from smtpo102.poczta.onet.pl (smtpo102.poczta.onet.pl [213.180.149.155]) by smtp4.osuosl.org (Postfix) with ESMTPS id 3E6EF402FA for ; Mon, 22 Mar 2021 07:56:09 +0000 (UTC) Received: from pmq7v.m5r2.onet (pmq7v.m5r2.onet [10.174.35.192]) by smtp.poczta.onet.pl (Onet) with ESMTP id 4F3ms038Bkz3jDd; Mon, 22 Mar 2021 08:51:00 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gazeta.pl; s=2013; t=1616399460; bh=Dlt7LQV7T6+KKPiiEOk6EukapFdDB0Um3x8oyJEzZg8=; h=From:To:Date:Subject:From; b=GD0CE0Bw+WfqBBsp7MfF1rtgmJBoBAOaFVwtpMNamsOLy30lxPea48hzop0q2ggZA QDX1NwsQq9gqZFhMFoSJt6mGFQjXkcTrb47Xrs6QI6tgTWTjiueYQng3u5eULzj1MH N4ZDuG+qgLvARkxev89TizjOS5vYD9RBreric0MA= Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Received: from [82.177.167.2] by pmq7v.m5r2.onet via HTTP id 202103220850106108010001; Mon, 22 Mar 2021 08:51:00 +0100 From: vjudeu X-Priority: 3 To: Tim Ruffing , "bitcoin-dev@lists.linuxfoundation.org" Date: Mon, 22 Mar 2021 08:51:00 +0100 Message-Id: <126012152-39f82455cdb5fc18203880bbba2d7b06@pmq7v.m5r2.onet> X-Mailer: onet.poczta X-Onet-PMQ: ;82.177.167.2;PL;2 X-Mailman-Approved-At: Mon, 22 Mar 2021 08:58:37 +0000 Subject: Re: [bitcoin-dev] An alternative to BIP 32? 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: Mon, 22 Mar 2021 07:56:11 -0000 > I can't really answer that question because it's not specified how "nonce= " is obtained. Nonce depends directly on your derivation path. By default, you can just st= art from 256-bit zero value and increment it if you want standard derivatio= n path. But optionally it can be something else that is unique, for example= username. So, if you have "0/0/0/0" derivation path, then you have four no= nces with 256-bit zero each time. But if you have '0/"bitcointalk.org"/5321= 992/"coinlatte"' derivation path (as mentioned by the author of this scheme= ), then your first nonce is 256-bit zero value, your second nonce is SHA-25= 6 of "bitcointalk.org", which is f245bd5620ee79314f48d9e9641a5406bd03745f6a= c516e2801ef6ccbfe40ced, your third nonce is 0000000000000000000000000000000= 000000000000000000000000000513508 and your fourth nonce is 314870494d3a9136= ba0a67ceb33534cbd438e982105d20cc076204c6fc99594d. There is an example in me= ntioned topic here: https://bitcointalk.org/index.php?topic=3D5321992.msg56= 503261#msg56503261 > the master private key is involved in the derivation of "nonce" (then "no= nce" may be unpredictable) It is impossible, because having some parent public key should be enough to= derive child public keys. But even if you know the nonce, you have no idea= what masterPublicKey was used in SHA-256 (that is the thing you are lookin= g for if you try to link addresses together). To see how difficult it is to get some parent key from some child key, you = can try going up the tree in the mentioned example. SHA-256 empty string is= e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855, but if u= sed directly, that leads us to some key starting with 03 prefix, so we shou= ld negate it and get 1c4f3bbd6703e3eb65040b37669046da93009b024aad0cef1b3cc5= 7157e388ec. Then, we have our child key 02 a34b99f22c790c4e36b2b3c2c35a36db= 06226e41c692fc82b8b56ac1c540c5bd and to break this scheme and prove that go= ing to the parent key is possible, we have to find something like this: masterPublicKey =3D attackerPublicKey + SHA256(attackerPublicKey || nonce) 02 a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd =3D att= ackerPublicKey + SHA-256(attackerPublicKey || 00000000000000000000000000000= 00000000000000000000000000000000000) For me, it seems that finding attackerPublicKey here is impossible. Of cour= se the absence of solution does not mean that it is secure, but I think it = is a good example to show how strong this scheme is. On 2021-03-21 22:45:19 user Tim Ruffing wrote: > On Sat, 2021-03-20 at 21:25 +0100, vjudeu via bitcoin-dev wrote: > > So, things have to be complicated to be secure? > = > Not at all. But we first need to spend some thoughts on what "secure" > means before we can tell if something is secure. > = > > By definition, using some private key, calculating some public key > > from it and incrementing that key is secure (it is definitely no > > worse than address reuse).=C2=A0 > = > If secure means that it does not hurt the unforgeability of ECDSA, then > I believe you're right. > = > > The only problem with using "privKey", "(privKey+1) mod n", > > "(privKey+2) mod n" and so on is that all of those public keys could > > be easily linked together. If that is the only problem, then by > > making offset deterministic but less predictable, it should be secure > > enough, right? So, instead of simple incrementation, we would have > > "privKey" (parent), "(privKey+firstOffset) mod n" (first child), > > "(privKey+secondOffset) mod n" (second child) and so on. And as long > > as this offset is not guessed by the attacker, it is impossible to > > link all of those keys together, right? > = > I believe this intuition is also a good first approach. So let's have a > look:=C2=A0 You say that offset =3D SHA256(masterPublicKey || nonce). Is = this > predictable by the attacker?=C2=A0 > = > I can't really answer that question because it's not specified how > "nonce" is obtained.=C2=A0 Since this is supposed to be a deterministic > scheme, I see two basic ways: Either the master private key is involved > in the derivation of "nonce" (then "nonce" may be unpredictable) or > it's not (then "nonce" is predictable). = > = > Another fact that may or not be a problem is that it may be possible to > compute a parent private key from the a private key. Again, I can't > tell because I don't know how nonce is obtained. = > = > Taking a step back, BIP 32 addresses all of these concerns. I agree it > could be simpler but I don't see a practical necessity to invent a new > scheme. In any application where this proposal could potentially be > used, BIP 32 could also be used and it's just good enough. > = > Tim = > = > = > > = > > > On 2021-03-20 11:08:30 user Tim Ruffing > > > wrote: > > > > On Fri, 2021-03-19 at 20:46 +0100, vjudeu via bitcoin-dev wrote: > > > > > is it safe enough to implement it and use in practice? > > > > = > > > > This may be harsh but I can assure you that a HD wallet scheme > > > > that can > > > > be specified in 3 lines (without even specifying what the > > > > security > > > > goals are) should not be assumed safe to implement. > > > > = > > > > Tim = > > > > = > > > > = > > > = > > = > > = > > = > > _______________________________________________ > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > = > = > =