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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <timo.hanke@web.de>) id 1VdLni-000807-R8
for bitcoin-development@lists.sourceforge.net;
Mon, 04 Nov 2013 15:10:46 +0000
Received: from mout.web.de ([212.227.17.12])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES128-SHA:128)
(Exim 4.76) id 1VdLnh-0005lz-CS
for bitcoin-development@lists.sourceforge.net;
Mon, 04 Nov 2013 15:10:46 +0000
Received: from crunch ([66.68.149.162]) by smtp.web.de (mrweb004) with ESMTPA
(Nemesis) id 0M5sDZ-1VsNe83EJV-00xpHK for
<bitcoin-development@lists.sourceforge.net>;
Mon, 04 Nov 2013 16:10:38 +0100
Date: Mon, 4 Nov 2013 09:10:36 -0600
From: Timo Hanke <timo.hanke@web.de>
To: Thomas Voegtlin <thomasv1@gmx.de>
Message-ID: <20131104151036.GN16611@crunch>
References: <526BDEC2.2090709@gmx.de>
<CAJna-HgH1g8iiSvxXrJuga808SQJ6DKo4AYw4fxpwTRCsL+EyQ@mail.gmail.com>
<CAPg+sBiuLJJV3pB-EF3O9sgB_Z3tuLhEg9k=A9mcxJvgy3UQSw@mail.gmail.com>
<52721F47.30206@gmx.de>
<CAJna-Hj+q7oyTj8SWiVESPt5Web-mLuDhv7yA8zF5wRD81aBXA@mail.gmail.com>
<5274C99A.8060304@gmx.de> <20131103064111.GI16611@crunch>
<5275F55A.1030805@gmx.de> <20131103074052.GJ16611@crunch>
<52760BCE.6080501@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <52760BCE.6080501@gmx.de>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Provags-ID: V03:K0:JLZX74I+jp+E3+nJyz2EHj6dxG9SxZxyGCA4YKPC+5ap7cgiboP
LqIjIDKB370sRdF8wpXgvtRk2hXnQ1Kwt77M7jYRVFMkh1f4Iec5js4vHWGh+XudM90bEEI
9LlLEdWV0GSpIJ0WzaHInXkanevHX0H7So5kkmbEdAHfQOe8F07gmXfyn8xMhoeZ7PR5CYI
HuGZINSdS/kOro3nB8V0w==
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [212.227.17.12 listed in list.dnswl.org]
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(timo.hanke[at]web.de)
-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
X-Headers-End: 1VdLnh-0005lz-CS
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Proposal to replace BIP0039
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: timo.hanke@web.de
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Mon, 04 Nov 2013 15:10:47 -0000
On Sun, Nov 03, 2013 at 09:39:42AM +0100, Thomas Voegtlin wrote:
>
> Le 03/11/2013 08:40, Timo Hanke a écrit :
> >I think the communication would have to go the other way around. Trezor
> >has to commit to a value First. Like this:
> >
> >Trezor picks random s and sends S=s*G to computer, keeping s secret.
> >Computer picks random t and sends t to Trezor. Trezor makes r := s+t
> >its internal master private key with corresponding master public key
> >R := (s+t)*G. Since R = S+t*G, the computer can verify the master
> >public key. As you say, the computer can then store R and can later
> >verify for each derived pubkey that it was indeed derived from R, hence
> >from his own entropy t.
>
> I'm not sure how this differs from what I wrote...
Sorry, yes, of course it's the same..
Your very first proposal was fine, provided that Trezor commits to its
random value first.
> However, if this is how it works, then my question remains:
> The computer has no proof to know that pubkeys derived through
> bip32's private derivations are derived from its own entropy...
> This verification would only work for public (aka type2) derivations.
>
> .. but maybe Trezor works in a different way? I think an explanation
> from slush would be needed.
Does Trezor even use private derivation?
Regardless of whether the derivation is private or public, and
regardless of what kind of proof you use to show that the master public
key was derived from user supplied entropy, my question also remains:
How do you verify your backup? The backup is a seed or private key. It's
too long to do any meaningful computation by hand. So you would need a
second offline device, eg a second Trezor in "restore mode", just to
verify your backup.
Timo
> >However, Trezor could not use straight bip32 out of the box. The
> >chaincode would have to be something like SHA(R). And the seed (that
> >gets translated to mnemonic) would be r itself, making it 256 bit
> >instead of only 128 bit.
> >
> >If the longer seed is bearable then this is a good way to do it.
> >
> >One question remains: if you only write down the mnemonic how can you be
> >sure that it is correct and corresponds to the secret in Trezor? You
> >cannot verify that on paper. You would have to restore it on some
> >device, eg another empty Trezor, and see if it brings up the same master
> >pubkey. Right?
> >
> I guess you have to trust Trezor that it derives R from r
>
>
>
>
--
Timo Hanke
PGP 1EFF 69BC 6FB7 8744 14DB 631D 1BB5 D6E3 AB96 7DA8
|
