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
|
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 <timo.hanke@web.de>) id 1Vcr5k-0007yb-RI
for bitcoin-development@lists.sourceforge.net;
Sun, 03 Nov 2013 06:23:20 +0000
Received: from mout.web.de ([212.227.17.12])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES128-SHA:128)
(Exim 4.76) id 1Vcr5i-0001Hl-EQ
for bitcoin-development@lists.sourceforge.net;
Sun, 03 Nov 2013 06:23:20 +0000
Received: from crunch ([66.68.149.162]) by smtp.web.de (mrweb103) with ESMTPA
(Nemesis) id 0MTPel-1VBWuX32Up-00SR1e for
<bitcoin-development@lists.sourceforge.net>;
Sun, 03 Nov 2013 07:23:11 +0100
Date: Sun, 3 Nov 2013 01:23:09 -0500
From: Timo Hanke <timo.hanke@web.de>
To: Johnathan Corgan <johnathan@corganlabs.com>
Message-ID: <20131103062309.GH16611@crunch>
References: <20131102050144.5850@gmx.com>
<52756B2E.7030505@corganlabs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <52756B2E.7030505@corganlabs.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Provags-ID: V03:K0:Q5mXUUwYYYD+6GCdEATcLRLIwiIeUd1IWPv/nyeykGAQXZcdUx8
gmwTVeU2yUcPjAe7cBTydynSVvw2C7zIITnyCpUx5Vlezz0GzppvEY8UYAb0jEZfBEr/oKl
0VW0NbSwRLaDhXNU/tR4EfXH8ZWdd/6AaRj7VDyYp8rPZe4BGaKSyFEBhwOv9YoKnHJl8Ea
4OYCFmnWTFeKecL6yB2Cw==
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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(timo.hanke[at]web.de)
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [212.227.17.12 listed in list.dnswl.org]
-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information. [URIs: gmx.com]
X-Headers-End: 1Vcr5i-0001Hl-EQ
Cc: bitcoingrant@gmx.com, bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Message Signing based authentication
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: timo.hanke@web.de
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: Sun, 03 Nov 2013 06:23:21 -0000
On Sat, Nov 02, 2013 at 02:14:22PM -0700, Johnathan Corgan wrote:
> On 11/01/2013 10:01 PM, bitcoingrant@gmx.com wrote:
>
> > Server provides a token for the client to sign.
>
> Anyone else concerned about signing an arbitrary string? Could be a
> hash of $EVIL_DOCUMENT, no? I'd want to XOR the string with my own
> randomly generated nonce, sign that, then pass the nonce and the
> signature back to the server for verification.
There were several replies like this, suggesting the client should
modify or add something to the token, or should give the token some
structure. But signing a token is not what the client should do in the
first place. At least not if the client's key is (EC)DSA. The standard
way is a challenge-response protocol in the form of the Diffie-Hellman
key exchange, which avoids producing any unintentional signatures.
Say the clients wants to prove he owns private key p, belonging to
public key P. P=p*G and G is the "base" of the (EC)DSA signature system.
The server generates a new keypair (a,A), a is private, A is public, and
sends A to the client as a challenge. The client computes and sends p*A
back. The server verifies whether p*A = a*P.
Only "public keys" are exchanged here, there's nothing that can be
mistaken for a (EC)DSA signature.
Timo
> --
> Johnathan Corgan, Corgan Labs
> SDR Training and Development Services
> http://corganlabs.com
> begin:vcard
> fn:Johnathan Corgan
> n:Corgan;Johnathan
> org:Corgan Enterprises LLC dba Corgan Labs
> adr:;;6081 Meridian Ave. Suite 70-111;San Jose;CA;95120;United States
> email;internet:johnathan@corganlabs.com
> title:Managing Partner
> tel;work:+1 408 463 6614
> x-mozilla-html:FALSE
> url:http://corganlabs.com
> version:2.1
> end:vcard
>
--
Timo Hanke
PGP 1EFF 69BC 6FB7 8744 14DB 631D 1BB5 D6E3 AB96 7DA8
|
