From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VcsIv-000686-Qo for bitcoin-development@lists.sourceforge.net; Sun, 03 Nov 2013 07:41:01 +0000 Received: from mout.web.de ([212.227.15.4]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.76) id 1VcsIu-0004UF-JM for bitcoin-development@lists.sourceforge.net; Sun, 03 Nov 2013 07:41:01 +0000 Received: from crunch ([66.68.149.162]) by smtp.web.de (mrweb004) with ESMTPA (Nemesis) id 0MBp3P-1VTD8M1kEJ-00Aq3r for ; Sun, 03 Nov 2013 08:40:54 +0100 Date: Sun, 3 Nov 2013 01:40:52 -0600 From: Timo Hanke To: Thomas Voegtlin Message-ID: <20131103074052.GJ16611@crunch> References: <526BDEC2.2090709@gmx.de> <52721F47.30206@gmx.de> <5274C99A.8060304@gmx.de> <20131103064111.GI16611@crunch> <5275F55A.1030805@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5275F55A.1030805@gmx.de> User-Agent: Mutt/1.5.21 (2010-09-15) X-Provags-ID: V03:K0:cneATRbODcwZiVPN9vr95j72h8E5SsT/+4TIhbqgUj4Wfk9m9OZ 7fhS3qjtSKUyKTDagNB9hHH4VbbrD3UkzvEbiiaw27DGlfxtN+JvVoCy2fNuRa1ZIIFy4Pc 4JfFwnCPR0gj6Eh78QutMnKVgEg2mj7T12dIyh4quVbhINdQz3MROXkn2LTgunj6QT/4HZu Ak6olD2RRkxXk0yhoktEA== 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.4 listed in list.dnswl.org] -0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-Headers-End: 1VcsIu-0004UF-JM 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2013 07:41:02 -0000 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. 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? Timo On Sun, Nov 03, 2013 at 08:03:54AM +0100, Thomas Voegtlin wrote: > > Le 03/11/2013 07:41, Timo Hanke a écrit : > >No. You mean the computer would use B for this check? (k,K) could > >be rigged by Trezor, who computes b as k-a. Timo > > I was just asking a question, in order to understand how this device > works, and what are its requirements. > if you think you can help, please explain. > > -- Timo Hanke PGP 1EFF 69BC 6FB7 8744 14DB 631D 1BB5 D6E3 AB96 7DA8