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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <thomasv1@gmx.de>) id 1VctDq-0001DH-GV
for bitcoin-development@lists.sourceforge.net;
Sun, 03 Nov 2013 08:39:50 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmx.de
designates 212.227.15.18 as permitted sender)
client-ip=212.227.15.18; envelope-from=thomasv1@gmx.de;
helo=mout.gmx.net;
Received: from mout.gmx.net ([212.227.15.18])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES128-SHA:128)
(Exim 4.76) id 1VctDp-0006Gl-En
for bitcoin-development@lists.sourceforge.net;
Sun, 03 Nov 2013 08:39:50 +0000
Received: from [192.168.1.27] ([86.73.30.143]) by mail.gmx.com (mrgmx003)
with ESMTPSA (Nemesis) id 0M2tXS-1Vt2vR02BK-00shHQ for
<bitcoin-development@lists.sourceforge.net>;
Sun, 03 Nov 2013 09:39:43 +0100
Message-ID: <52760BCE.6080501@gmx.de>
Date: Sun, 03 Nov 2013 09:39:42 +0100
From: Thomas Voegtlin <thomasv1@gmx.de>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
CC: bitcoin-development@lists.sourceforge.net
References: <trinity-ba3941a0-f758-4372-b431-c64e9b44328a-1382635758149@3capp-gmx-bs09>
<CAJna-HjgpRhLdVGh+prx54VezHaH1vXGpPotW1Xkz2tiAiWrbg@mail.gmail.com>
<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>
In-Reply-To: <20131103074052.GJ16611@crunch>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K0:aer7yH1iNS0Gr90sV/caN/Ya0dX3yUEtvvaYdvSis2nNsPcPGrn
gvC0Sd71sKB9r9CFO25w/Pd62dykssylJ4i74zsOVg+ozIxnoZYvA0bO2UXB3gk8DlJG2ra
ma7FZOBeJK6uNW6PneupGXNsjBQNG+OtTeV8CVC0N3j50vW5pFkoKp0mBdZgwT/26YqXDey
e1oHjvAUhMsWBGvIO7bEA==
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.15.18 listed in list.dnswl.org]
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(thomasv1[at]gmx.de)
-0.0 SPF_PASS SPF: sender matches SPF record
0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in
digit (thomasv1[at]gmx.de)
1.2 MISSING_HEADERS Missing To: header
X-Headers-End: 1VctDp-0006Gl-En
Subject: Re: [Bitcoin-development] Proposal to replace BIP0039
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
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, 03 Nov 2013 08:39:50 -0000
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...
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.
> 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
|
