From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from <timo.hanke@web.de>) id 1VcrNC-0005AW-6W for bitcoin-development@lists.sourceforge.net; Sun, 03 Nov 2013 06:41:22 +0000 Received: from mout.web.de ([212.227.15.14]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.76) id 1VcrNA-00022A-IL for bitcoin-development@lists.sourceforge.net; Sun, 03 Nov 2013 06:41:22 +0000 Received: from crunch ([66.68.149.162]) by smtp.web.de (mrweb102) with ESMTPA (Nemesis) id 0MJCSM-1VfcWZ1FSE-002qlc for <bitcoin-development@lists.sourceforge.net>; Sun, 03 Nov 2013 07:41:14 +0100 Date: Sun, 3 Nov 2013 01:41:11 -0500 From: Timo Hanke <timo.hanke@web.de> To: Thomas Voegtlin <thomasv1@gmx.de> Message-ID: <20131103064111.GI16611@crunch> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5274C99A.8060304@gmx.de> User-Agent: Mutt/1.5.21 (2010-09-15) X-Provags-ID: V03:K0:UlP5dCHoGuomhmnSpf7SILK31iHfzKdpr0vdM7KPkBWxwMegUWl 3t426oXpAZd4jFEkwIyY8bESR7a8yvxtTDi8gDECMX/XFNlI1oCzcOee8mbqJgClFBWH47V wOune7VqUq3N5TumRKncPdODn4ejWA35ZwcXlGMXLE5pfDmOnMtP0L4IGWwVWcE3YR7DwTm qRavC3Avrsw1Q1ncx0twQ== 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.14 listed in list.dnswl.org] -0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-Headers-End: 1VcrNA-00022A-IL 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, 03 Nov 2013 06:41:22 -0000 On Sat, Nov 02, 2013 at 10:44:58AM +0100, Thomas Voegtlin wrote: > > >To be specific, we (in cooperation with / inspired by Timo Hanke) > >developed method how to prove that the seed generated by Trezor > >has been created using combination of computer-provided entropy > >and device-provided entropy, without leaking full private > >information to other computer, just because we want Trezor to be > >blackbox-testable and fully deterministic (seed generation is > >currently the only operation which uses any source of RNG). > > > > Thanks for the explanation. Here is how I understand how it works, > please correct me if I'm wrong: > > The user's computer picks a random number a, the Trezor picks a > random number b. > Trezor adds a and b in the secp256k1 group, and this creates a > master private key k. > Trezor sends the corresponding master public key K to the computer. > Thus, the computer can check that K was derived from a, without knowing b. 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 > This also allows the computer to check that any bitcoin address > derived from K is derived from a, without leaking b. (and > reciprocally) > > However, it seems to me that this property will work only with bip32 > public derivations; if a private derivation is used, don't you need > to know k? > > > -- Timo Hanke PGP 1EFF 69BC 6FB7 8744 14DB 631D 1BB5 D6E3 AB96 7DA8