1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
|
Return-Path: <crypto@timruffing.de>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 49DFCC0001
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 21 Mar 2021 21:51:35 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id 2407C40289
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 21 Mar 2021 21:51:35 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.801
X-Spam-Level:
X-Spam-Status: No, score=-2.801 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, RCVD_IN_DNSWL_LOW=-0.7,
SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=timruffing.de
Received: from smtp2.osuosl.org ([127.0.0.1])
by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id ViNJ-SR6sCnB
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 21 Mar 2021 21:51:33 +0000 (UTC)
X-Greylist: delayed 00:06:04 by SQLgrey-1.8.0
Received: from mout-p-101.mailbox.org (mout-p-101.mailbox.org
[IPv6:2001:67c:2050::465:101])
by smtp2.osuosl.org (Postfix) with ESMTPS id 481EF40287
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 21 Mar 2021 21:51:33 +0000 (UTC)
Received: from smtp2.mailbox.org (smtp2.mailbox.org [80.241.60.241])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest
SHA256) (No client certificate requested)
by mout-p-101.mailbox.org (Postfix) with ESMTPS id 4F3WQD0Rd5zQjmc;
Sun, 21 Mar 2021 22:45:24 +0100 (CET)
X-Virus-Scanned: amavisd-new at heinlein-support.de
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=timruffing.de;
s=MBO0001; t=1616363121;
h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
to:to:cc:mime-version:mime-version:content-type:content-type:
content-transfer-encoding:content-transfer-encoding:
in-reply-to:in-reply-to:references:references;
bh=PvZ80JWqZVGAah/hdsouq9zqhfbN5gt277514pBezAw=;
b=KWAqIss/PV05j7ytpQ5b/AgXQsaD6mtOaSRuVHNf98KZE9w6h2aTDsJgMfwR0KwAxAbbpQ
Fjk9beSidxJ9lh19/MNHOIa6k+UxSRN+SyIrPoanLA0U8XmqZwRN58ZPEA1Zsv1o1pkj7y
vSKzbl+01mUTsy7otX0mmZHcGRVWgd4SskrAoNNQxdq814ILNzMqZfN8ce/wLdOs+1qBNL
Le0T8G0PgYv6fIzSZ3VNt8mOmP+Lmv2VtWJPuNfDHPSWlHi7gFG/gLzfUwN+KzJd0XuQD2
Lq7dqB+Z5m89eRXdTrcUVZcApJO8lDTN1XblJBQce99vb52fUyyXssS61gU+LQ==
Received: from smtp2.mailbox.org ([80.241.60.241])
by spamfilter01.heinlein-hosting.de (spamfilter01.heinlein-hosting.de
[80.241.56.116]) (amavisd-new, port 10030)
with ESMTP id i0wdUuZhbSz5; Sun, 21 Mar 2021 22:45:20 +0100 (CET)
Message-ID: <616d3364b01dd392c86b7dbd1b6b6f5786bc7d67.camel@timruffing.de>
From: Tim Ruffing <crypto@timruffing.de>
To: vjudeu <vjudeu@gazeta.pl>, Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>
Date: Sun, 21 Mar 2021 22:45:19 +0100
In-Reply-To: <126113469-4f8fddbc2594365c5558c0e75fa55917@pmq5v.m5r2.onet>
References: <126113469-4f8fddbc2594365c5558c0e75fa55917@pmq5v.m5r2.onet>
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-MBO-SPAM-Probability:
X-Rspamd-Score: -4.83 / 15.00 / 15.00
X-Rspamd-Queue-Id: BE6E516F3
X-Rspamd-UID: cc01ec
X-Mailman-Approved-At: Sun, 21 Mar 2021 22:05:58 +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: Sun, 21 Mar 2021 21:51:35 -0000
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).
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: You say that offset = SHA256(masterPublicKey || nonce). Is this
predictable by the attacker?
I can't really answer that question because it's not specified how
"nonce" is obtained. 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
|
