path: root/b2/256b069ebd29383e067e61a665c1a4a87a9a76

Return-Path: <vjudeu@gazeta.pl>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 61294C0001
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <vjudeu@gazeta.pl>
X-Priority: 3
To: Tim Ruffing <crypto@timruffing.de>, "bitcoin-dev@lists.linuxfoundation.org"
 <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: <vjudeu@gazeta.pl>;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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <crypto@timruffing.de> 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 <crypto@timruffing.de>
> > > 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
> =

> =

> =