From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UpOb5-0003rL-EN for bitcoin-development@lists.sourceforge.net; Wed, 19 Jun 2013 20:03:15 +0000 Received: from mout.web.de ([212.227.15.4]) by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1UpOb4-0004CQ-14 for bitcoin-development@lists.sourceforge.net; Wed, 19 Jun 2013 20:03:15 +0000 Received: from crunch ([217.50.172.120]) by smtp.web.de (mrweb103) with ESMTPA (Nemesis) id 0Lmcf9-1UG3mC3KcN-00aBZp; Wed, 19 Jun 2013 22:03:08 +0200 Date: Wed, 19 Jun 2013 22:03:07 +0200 From: Timo Hanke To: Alan Reiner Message-ID: <20130619200307.GB20405@crunch> References: <51BFD886.8000701@gmail.com> <20130619142510.GA17239@crunch> <51C1C288.4000305@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51C1C288.4000305@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Provags-ID: V03:K0:t05g5UVZi/Etv7wueDCJSKhu2n0sowPJTAkmgB1mZtdwfL+MEt3 pil/8O4g8jsy3aFlaCBwsnA/qO/qhKZrFXSjugxS2QxSQzNrDvE9ALWoiQmmHJtg3VBChCy QXIK0oNflXSX8VMsMRLSBvco9F4+hPp943gLc9BrzzhLq2tpwmT6ggZW1aKZJv42edyDcK9 JTfPnrk/a7FTeg6XY27Bw== X-Spam-Score: -1.3 (-) 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.4 listed in list.dnswl.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (timo.hanke[at]web.de) -1.3 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-Headers-End: 1UpOb4-0004CQ-14 Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Optional "wallet-linkable" address format - Payment Protocol 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: Wed, 19 Jun 2013 20:03:15 -0000 On Wed, Jun 19, 2013 at 10:39:04AM -0400, Alan Reiner wrote: > On 06/19/2013 10:25 AM, Timo Hanke wrote: > > Since you mention to use this in conjunction with the payment protocol, > > note the following subtlety. Suppose the payer has to paid this address > > called "destination": > >> Standard Address ~ Base58(0x00 || hash160(PubKeyParent * Multiplier[i]) || > >> checksum) > > Also suppose the payee has spent the output, i.e. the pubkey > > corresponding to "destination", which is PubKeyParent * Multiplier[i], > > is publicly known. Then anybody can (in retrospect) create arbitrary > > many pairs {PublicKeyParent, Multiplier} (in particular different > > PublicKeyParent) that lead to the same "destination". > > > > Depending on what you have in mind that the transaction should "prove" > > regarding its actual receiver or regarding the receiver's PubKeyParent, > > this could be an unwanted feature (or it could be just fine). If it is > > unwanted then I suggest replacing > > PubKeyParent * Multiplier[i] by > > PubKeyParent * HMAC(Multiplier[i],PubKeyParent) > > which eliminates from the destination all ambiguity about PubKeyParent. > > > > This modification would not be directly compatible with BIP32 anymore > > (unfortunately), but seems to be better suited for use in conjunction > > with a payment protocol. > > > > Timo > > It's an interesting observation, but it looks like the most-obvious > attack vector is discrete log problem: spoofing a relationship between > a target public key and one that you control. For instance, if you see > {PubA, Mult} produces PubB and you have PubC already in your control > that you want to "prove" [maliciously] is related to PubB, then you have > to find the multiplier, M that solves: M*PubC = PubB. That's a > discrete logarithm problem. Correct, for a given PubC in advance you can't create such a "malicious" relation to PubB. You can only "reversely" construct new PubC from given PubB. > I'm not as familiar as you are, with the available operations on > elliptic curves, but it sounds like you can produce essentially-random > pairs of {PubX, Mult} pairs that give the same PubB, but you won't have > the private key associated with those public keys. Depends on who is "you". The arbitrary person who produces {PubX, Mult} won't have the private key, but the person who knows the private key for PubA will have it (assuming that PubB was computed from {PubA, Mult} in the first place). In the end, it all depends on your application. What proves enough for one party doing repeated transactions with another may not suffice for a third party doing auditing. On the other hand, ambiguity about PubA may just as well be a wanted feature for deniability reasons. Timo -- Timo Hanke PGP 1EFF 69BC 6FB7 8744 14DB 631D 1BB5 D6E3 AB96 7DA8