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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <timo.hanke@web.de>) id 1VhqRt-0007Bx-J0
for bitcoin-development@lists.sourceforge.net;
Sun, 17 Nov 2013 00:42:49 +0000
Received: from mout.web.de ([212.227.15.3])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES128-SHA:128)
(Exim 4.76) id 1VhqRs-0002KU-GV
for bitcoin-development@lists.sourceforge.net;
Sun, 17 Nov 2013 00:42:49 +0000
Received: from crunch ([66.68.149.162]) by smtp.web.de (mrweb103) with ESMTPA
(Nemesis) id 0M4I2R-1VRHMo10Jn-00rsJx for
<bitcoin-development@lists.sourceforge.net>;
Sun, 17 Nov 2013 01:42:42 +0100
Date: Sat, 16 Nov 2013 18:42:39 -0600
From: Timo Hanke <timo.hanke@web.de>
To: Pavol Rusnak <stick@gk2.sk>
Message-ID: <20131117004239.GA24383@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>
<52880470.2060206@gk2.sk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <52880470.2060206@gk2.sk>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Provags-ID: V03:K0:egyXhVr34/SJ/kBNTjKKD8qa0TE97zdyDobQgd+iXJdvfMJYcfl
vHE7t/152/sexVTMz/EfwNlT9wvnqxPmqGUK7AWYHgO/moEA3x3wF91Zu/A3sCFM33hB7ta
Q6S6Lw8j3fIljO24WG5hMdqXkY04q4vWmgonh5fYRR0ONc3m1aRxkbSJWQe0FMBLQZsogGH
/P9Gvl2Hw0DdtpBh4VnHg==
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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(timo.hanke[at]web.de)
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [212.227.15.3 listed in list.dnswl.org]
-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
X-Headers-End: 1VhqRs-0002KU-GV
Cc: 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: Sun, 17 Nov 2013 00:42:49 -0000
On Sun, Nov 17, 2013 at 12:49:04AM +0100, Pavol Rusnak wrote:
> On 03/11/13 08:40, Timo Hanke wrote:
> > Trezor picks random s and sends S=s*G to computer, keeping s secret.
>
> That's a really neat trick!
>
> > 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?
>
> Right. That's a problem. I'm not sure if this whole cryptomagic is
> benefitial at all.
>
> I'd suggest to go the easy way for now, i.e. prove that external entropy
> was used while generating the master seed. If the user does not trust
> our firmware, he can use his own built one.
No, this question of mine was regardless of any cryptomagic or neat
tricks like Thomas' suggestion. It has nothing do with auditing the
entropy. It was just a backup question.
I recently had an experience where I thought coins were lost because the
secrets I had didn't match the public keys that I thought they'd match.
From now on I will always recover my wallet first, from the backed up
secrets, before sending any coins to the pubkeys in the wallet. I will
never again generate a wallet, backup the secrets, and hope the secrets
indeed match the pubkeys.. without testing that. My question was how
Trezor allows me to verify my backup.
All this makes me think if having one device generating and displaying
the secret, and making a backing from the display, is the right way to
go. Since you would need a second device to verify your backup is sane,
you could have two devices to start with. One is your hardware wallet
and it only imports secrets (restores backups). The other is an entropy
generator and it only generates secrets.
Best regards,
Timo
p.s. The question about auditing entropy would only apply to the generator,
not the wallet. Is it yet documented how Trezor proves that external
entropy was used?
--
Timo Hanke
PGP 1EFF 69BC 6FB7 8744 14DB 631D 1BB5 D6E3 AB96 7DA8
|
