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-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UpZbm-0007in-9J for bitcoin-development@lists.sourceforge.net; Thu, 20 Jun 2013 07:48:42 +0000 Received: from mout.web.de ([212.227.15.14]) by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1UpZbj-0004yr-TK for bitcoin-development@lists.sourceforge.net; Thu, 20 Jun 2013 07:48:42 +0000 Received: from crunch ([137.226.152.116]) by smtp.web.de (mrweb102) with ESMTPA (Nemesis) id 0MBCNl-1UziUV2mYv-00ADd7; Thu, 20 Jun 2013 09:48:30 +0200 Date: Thu, 20 Jun 2013 09:48:30 +0200 From: Timo Hanke To: Adam Back Message-ID: <20130620074830.GA21724@crunch> References: <51BFD886.8000701@gmail.com> <20130619142510.GA17239@crunch> <51C1C288.4000305@gmail.com> <20130619152815.GA14729@netbook.cypherspace.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130619152815.GA14729@netbook.cypherspace.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Provags-ID: V03:K0:id66eJFZbmp3KSKNciQFBxJ94Gsr1CpdwyYYY01oZv3B8aq/DyH DcGfuJ7dKr1XOMzOP2fJ3VYhNh/i+npEcTr89JpDOXiGut6e0qQOYwvjE1NP0dvoyTJVcrh TyZ8MyQf3m3YvNpwTNIbOrlQbHl8G6wIk3tYlrZfoKdHqKXQvoMoJRfU0EU1xbOUZoE88WG 4cvqRlFNMe5XsDX6tqovA== 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.14 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: 1UpZbj-0004yr-TK 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: Thu, 20 Jun 2013 07:48:42 -0000 On Wed, Jun 19, 2013 at 05:28:15PM +0200, Adam Back wrote: > I think Timo's point is that while you cant do discrete log, you can do y-th > root. So if P = xG is a parent public key (x private key, G base point), > then your proposed multiplier address is hash of Q=yP. However its easy to > find another P such that Q=zP'. ie just "divide by z" (EC multiply by z^-1 > mod n, n the order of the curve). So P'=z^-1.Q, which will work because > Q=zP', substituting P' you get Q=z.z^-1.Q, Q=Q. > > Of course the attacker has just performed an unspenable DoS (maybe, or maybe > a useless collision) because he wont know the discrete log of Q, nor P, nor > P'. So thats the question, does the protocol have any reliance on knowing > the discrete log - is it a problem if someone can find different multipliers > of different (unknown, uncomputable discrete log) parent keys. > > If it was a concern I guess you could require a proof of knowledge of > discrete log. ie as well as public key parent, multiplier the address must > include ECDSA sig or Schnorr proof of knowledge (which both demonstrate > knowledge of the discrete log of Q to base G.) The "concern" (if there is any) would be that the owner of the parent P=xG, i.e. the person knowing x, in addition to y creates another pair (P',z) such that yP=Q=zP' and uses that second pair maliciously later on (such as claiming the payment went to identity P' not P). Since the owner of P knows the private key for P' (x*y*z^-1) he can also produce proof of knowledge for discrete log for P'. I think adding proof of knowledge or signatures on the multiplier don't help to eliminate all possible concerns, which could involve proving something to a third party that has not seen the communication between payer and payee. If you consider only payer and payee then Alan's original proposal is just fine, as far as I can tell. Only if you start using it in a payment protocol or, more precisely, if you start interpreting P as an identity (as Alan suggested in subsequent posts) _and_ this identity is a public/global one rather than a local one that only the payer uses, then reasons can pop up to eliminate ambiguity about which identity each payment went to. Timo ps the fact that this post used the multiplicative rather than additive derivation scheme doesn't change the argument. -- Timo Hanke PGP 1EFF 69BC 6FB7 8744 14DB 631D 1BB5 D6E3 AB96 7DA8