Timo Hanke [ARCHIVE] on Nostr: 📅 Original date posted:2013-11-03 📝 Original message:On Sat, Nov 02, 2013 at ...
📅 Original date posted:2013-11-03
📝 Original message:On Sat, Nov 02, 2013 at 02:14:22PM -0700, Johnathan Corgan wrote:
> On 11/01/2013 10:01 PM, bitcoingrant at 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 at 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
📝 Original message:On Sat, Nov 02, 2013 at 02:14:22PM -0700, Johnathan Corgan wrote:
> On 11/01/2013 10:01 PM, bitcoingrant at 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 at 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