From: Timo Hanke <timo.hanke@web•de>
To: Johnathan Corgan <johnathan@corganlabs•com>
Cc: bitcoingrant@gmx•com, bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Message Signing based authentication
Date: Sun, 3 Nov 2013 01:23:09 -0500 [thread overview]
Message-ID: <20131103062309.GH16611@crunch> (raw)
In-Reply-To: <52756B2E.7030505@corganlabs.com>
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
next prev parent reply other threads:[~2013-11-03 6:23 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-02 5:01 bitcoingrant
2013-11-02 5:54 ` Luke-Jr
2013-11-02 13:02 ` Mike Hearn
2013-11-02 13:16 ` Melvin Carvalho
2013-11-02 13:19 ` Hannu Kotipalo
2013-11-02 16:26 ` Mike Hearn
2013-11-02 16:26 ` Mike Hearn
2013-11-02 16:52 ` Melvin Carvalho
2013-11-02 17:08 ` Jeff Garzik
2013-11-02 17:16 ` Hannu Kotipalo
2013-11-02 21:14 ` Johnathan Corgan
2013-11-02 21:51 ` Mark Friedenbach
2013-11-03 0:29 ` Allen Piscitello
2013-11-03 0:33 ` Luke-Jr
2013-11-03 1:19 ` Allen Piscitello
2013-11-03 1:27 ` Luke-Jr
2013-11-03 1:36 ` Allen Piscitello
2013-11-03 6:23 ` Timo Hanke [this message]
2013-11-06 3:38 ` Melvin Carvalho
2013-11-02 21:57 ` slush
2013-11-06 3:01 ` Melvin Carvalho
2013-11-06 6:41 ` slush
2013-12-06 10:44 ` Melvin Carvalho
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20131103062309.GH16611@crunch \
--to=timo.hanke@web$(echo .)de \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=bitcoingrant@gmx$(echo .)com \
--cc=johnathan@corganlabs$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox