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 1WMLmt-0003gn-0w for bitcoin-development@lists.sourceforge.net; Sat, 08 Mar 2014 18:15:55 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 74.125.82.173 as permitted sender) client-ip=74.125.82.173; envelope-from=natanael.l@gmail.com; helo=mail-we0-f173.google.com; Received: from mail-we0-f173.google.com ([74.125.82.173]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WMLmr-0005YX-Tx for bitcoin-development@lists.sourceforge.net; Sat, 08 Mar 2014 18:15:54 +0000 Received: by mail-we0-f173.google.com with SMTP id w61so6703647wes.18 for ; Sat, 08 Mar 2014 10:15:47 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.78.77 with SMTP id z13mr145447wjw.64.1394302547749; Sat, 08 Mar 2014 10:15:47 -0800 (PST) Received: by 10.194.54.10 with HTTP; Sat, 8 Mar 2014 10:15:47 -0800 (PST) Received: by 10.194.54.10 with HTTP; Sat, 8 Mar 2014 10:15:47 -0800 (PST) In-Reply-To: <20140308174101.GA21902@netbook.cypherspace.org> References: <531AD080.40501@gmail.com> <531AF2EA.50904@gmail.com> <20140308174101.GA21902@netbook.cypherspace.org> Date: Sat, 8 Mar 2014 19:15:47 +0100 Message-ID: From: Natanael To: Adam Back Content-Type: multipart/alternative; boundary=047d7bfcfc9811739304f41c5c28 X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -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 (natanael.l[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1WMLmr-0005YX-Tx Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] Is this a safe thing to be doing with ECC addition? (Oracle protocol) X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2014 18:15:55 -0000 --047d7bfcfc9811739304f41c5c28 Content-Type: text/plain; charset=UTF-8 You can always use a secure multiparty computation algorithm to do it. https://en.wikipedia.org/wiki/Secure_multi-party_computation But those aren't the fastest algorithms in the world, and usually both participants needs to be online at the same time. I guess most people would prefer a two-step algorithm that can be performed asynchronously. - Sent from my phone Den 8 mar 2014 18:44 skrev "Adam Back" : > Also the other limitation for ECDSA is that there is no known protocol to > create a signture with a+b (where keys P=aG, Q=bG, R=P+Q=(a+b)G). without > either a sending its private key to b or viceversa (or both to a third > party). > > With Schnorr sigs you can do it, but the k^-1 term in ECDSA makes a > (secure) > direct multiparty signature quite difficult. > > ps probably only 1 party needs to hash their key > > P=aG > H(P) -> > > <- Q=bG > > P -> > > Adam > > On Sat, Mar 08, 2014 at 12:37:30PM +0200, Joel Kaartinen wrote: > > If both parties insist on seeing a hash of the other party's public key > > before they'll show their own public key, they can be sure that the > > public key is not chosen based on the public key they themselves > > presented. > > > ------------------------------------------------------------------------------ > Subversion Kills Productivity. Get off Subversion & Make the Move to > Perforce. > With Perforce, you get hassle-free workflows. Merge that actually works. > Faster operations. Version large binaries. Built-in WAN optimization and > the > freedom to use Git, Perforce or both. Make the move to Perforce. > > http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > --047d7bfcfc9811739304f41c5c28 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

You can always use a secure multiparty computation algorithm= to do it.

https://en.wikipedia.org/wiki/Secure_multi-party_computation

But those aren't the fastest algorithms in the world, an= d usually both participants needs to be online at the same time. I guess mo= st people would prefer a two-step algorithm that can be performed asynchron= ously.

- Sent from my phone

Den 8 mar 2014 18:44 skrev "Adam Back"= <adam@cypherspace.org>:<= br type=3D"attribution">
Also the other limitation for ECDSA is that there is no known protocol to create a signture with a+b (where keys P=3DaG, Q=3DbG, R=3DP+Q=3D(a+b)G). w= ithout
either a sending its private key to b or viceversa (or both to a third
party).

With Schnorr sigs you can do it, but the k^-1 term in ECDSA makes a (secure= )
direct multiparty signature quite difficult.

ps probably only 1 party needs to hash their key

P=3DaG
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 H(P) ->

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <- Q=3DbG

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0P ->

Adam

On Sat, Mar 08, 2014 at 12:37:30PM +0200, Joel Kaartinen wrote:
> =C2=A0 If both parties insist on seeing a hash of the other party'= s public key
> =C2=A0 before they'll show their own public key, they can be sure = that the
> =C2=A0 public key is not chosen based on the public key they themselve= s
> =C2=A0 presented.

---------------------------------------------------------------------------= ---
Subversion Kills Productivity. Get off Subversion & Make the Move to Pe= rforce.
With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. =C2=A0Built-in WAN optimization = and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gam= pad/clk?id=3D122218951&iu=3D/4140/ostg.clktrk
_______________________________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment
--047d7bfcfc9811739304f41c5c28--