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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <adam@cypherspace.org>) id 1WMLFP-0002RU-EP
for bitcoin-development@lists.sourceforge.net;
Sat, 08 Mar 2014 17:41:19 +0000
X-ACL-Warn:
Received: from mout.perfora.net ([74.208.4.194])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WMLFO-0000ug-3s
for bitcoin-development@lists.sourceforge.net;
Sat, 08 Mar 2014 17:41:19 +0000
Received: from netbook (108-193-6-130.lightspeed.sntcca.sbcglobal.net
[108.193.6.130])
by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis)
id 0MYwiB-1WhSkb3MkF-00VtYZ; Sat, 08 Mar 2014 12:41:10 -0500
Received: by netbook (Postfix, from userid 1000)
id 212042E50BC; Sat, 8 Mar 2014 09:41:05 -0800 (PST)
Received: by flare (hashcash-sendmail, from uid 1000);
Sat, 8 Mar 2014 09:41:02 -0800
Date: Sat, 8 Mar 2014 09:41:01 -0800
From: Adam Back <adam@cypherspace.org>
To: Joel Kaartinen <joel.kaartinen@gmail.com>
Message-ID: <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <531AF2EA.50904@gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Hashcash: 1:20:140308:joel.kaartinen@gmail.com::8Gxp9qsw9sjtHJA0:0000000000000
0000000000000000000000009lYd
X-Hashcash: 1:20:140308:bitcoin-development@lists.sourceforge.net::2OrPjJChDmnOm
/9Y:000000000000000000001Fpg
X-Hashcash: 1:20:140308:adam@cypherspace.org::50dPkpLrAlElRdM9:00000000000000000
0000000000000000000000001WHo
X-Provags-ID: V02:K0:oEtAQOo+BzRTQ1KeCkBi2LKqeUzZeLggbS832Grp7KS
N1Q3+eyIYr+IGq3kdRj4a4Cagwt4+urN99VKODuh54xllrcALI
34jazW+M+B82QKmZ/YjlXgNSYKU2hxtN6MblesFubhSoDOS9GC
A1aZqlAdczIMK3nQFEIzHBcXQQ66vMHA36FGfO7DK6Oc/dNSDS
btGt0mC4VUlF7GOj+B56QTCywWiZkBR4N5oDXKEx9x78xUktIy
2fGcx15gMfy9AopotTwLHi1KRYxOJ9rZFOQ3i4PMaq6xo72pMa
K0OX2gszu2y3Aw4mnGUbu6THgGBbOtjyowLQM70dlOV3dP0J17
6bJTAIhWFs8uJ3LJYm33t6LrE+7oqEvCPfjt6OOkK
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 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [74.208.4.194 listed in list.dnswl.org]
-0.0 SPF_HELO_PASS SPF: HELO matches SPF record
X-Headers-End: 1WMLFO-0000ug-3s
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 17:41:19 -0000
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.
|
