summaryrefslogtreecommitdiff
path: root/dd/c2f49ecfaef6db20469fde77b7ab7b3aa2c6ec
blob: 4f2c6b6ea1bfe203148559c9409bc6cd38d678e8 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
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 <natanael.l@gmail.com>) 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 <bitcoin-development@lists.sourceforge.net>;
	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: <CA+su7OUMgeWgkMFAmmMEpW3eN=cvU47MKt51idDrmCWEiCb+VQ@mail.gmail.com>
	<531AD080.40501@gmail.com>
	<CA+su7OWx9jrgUJrOH=tg1968vr1G1w7yXjgaRSyYJ0zRBjwpqg@mail.gmail.com>
	<531AF2EA.50904@gmail.com>
	<20140308174101.GA21902@netbook.cypherspace.org>
Date: Sat, 8 Mar 2014 19:15:47 +0100
Message-ID: <CAAt2M18Jcfo8nFBM+PppkWhmWhF4bd3fpRL2--=jZw4We1-kPw@mail.gmail.com>
From: Natanael <natanael.l@gmail.com>
To: Adam Back <adam@cypherspace.org>
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: <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: 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" <adam@cypherspace.org>:

> 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

<p dir=3D"ltr">You can always use a secure multiparty computation algorithm=
 to do it. </p>
<p dir=3D"ltr"><a href=3D"https://en.wikipedia.org/wiki/Secure_multi-party_=
computation">https://en.wikipedia.org/wiki/Secure_multi-party_computation</=
a></p>
<p dir=3D"ltr">But those aren&#39;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.</p>

<p dir=3D"ltr">- Sent from my phone</p>
<div class=3D"gmail_quote">Den 8 mar 2014 18:44 skrev &quot;Adam Back&quot;=
 &lt;<a href=3D"mailto:adam@cypherspace.org">adam@cypherspace.org</a>&gt;:<=
br type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Also the other limitation for ECDSA is that there is no known protocol to<b=
r>
create a signture with a+b (where keys P=3DaG, Q=3DbG, R=3DP+Q=3D(a+b)G). w=
ithout<br>
either a sending its private key to b or viceversa (or both to a third<br>
party).<br>
<br>
With Schnorr sigs you can do it, but the k^-1 term in ECDSA makes a (secure=
)<br>
direct multiparty signature quite difficult.<br>
<br>
ps probably only 1 party needs to hash their key<br>
<br>
P=3DaG<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 H(P) -&gt;<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &lt;- Q=3DbG<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0P -&gt;<br>
<br>
Adam<br>
<br>
On Sat, Mar 08, 2014 at 12:37:30PM +0200, Joel Kaartinen wrote:<br>
&gt; =C2=A0 If both parties insist on seeing a hash of the other party&#39;=
s public key<br>
&gt; =C2=A0 before they&#39;ll show their own public key, they can be sure =
that the<br>
&gt; =C2=A0 public key is not chosen based on the public key they themselve=
s<br>
&gt; =C2=A0 presented.<br>
<br>
---------------------------------------------------------------------------=
---<br>
Subversion Kills Productivity. Get off Subversion &amp; Make the Move to Pe=
rforce.<br>
With Perforce, you get hassle-free workflows. Merge that actually works.<br=
>
Faster operations. Version large binaries. =C2=A0Built-in WAN optimization =
and the<br>
freedom to use Git, Perforce or both. Make the move to Perforce.<br>
<a href=3D"http://pubads.g.doubleclick.net/gampad/clk?id=3D122218951&amp;iu=
=3D/4140/ostg.clktrk" target=3D"_blank">http://pubads.g.doubleclick.net/gam=
pad/clk?id=3D122218951&amp;iu=3D/4140/ostg.clktrk</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</blockquote></div>

--047d7bfcfc9811739304f41c5c28--