1
$\begingroup$

A client identifies itself as a curve25519 public key. The server wants to verify the client owns the associated private key. Is there a safe and computationally efficient way of doing so? Which approach could be regarded to be “the most recommendable” from a safety point of view, while keeping it computationally efficient?

The community seems unsure whether curve25519 can be used for ECDSA. It should be safe to authenticate a nonce using a secret-key agreed with ECDH, but wouldn't ECDH itself be enough? The server sends a one-time use public key, the client returns a hash of the ECDH shared key and the server compares it.

Improve this question
$\endgroup$
9
  • 2
    $\begingroup$ 1) Authentication always needs to be bound to something. A message or an integrity protected channel. You cannot just authenticate. 2) Your scheme suffers from trivial forwarding attacks where an attacker impersonates the server to learn shared keys. 3) You need to apply some form of MAC, not the key itself. Else an attacker impersonating a server can learn arbitrary shared keys. $\endgroup$
    – CodesInChaos
    Commented Feb 12, 2014 at 8:47
  • $\begingroup$ You should use an existing higher level protocol, like CurveCP. You're not ready yet to design your own protocol. $\endgroup$
    – CodesInChaos
    Commented Feb 12, 2014 at 8:49
  • $\begingroup$ 1) It is bound to a tcp connection. If arbitrary data is needed, the server can send a nonce. 2) how about a hash of the shared key ? $\endgroup$
    – Kai Elvin
    Commented Feb 12, 2014 at 8:52
  • $\begingroup$ Also, I do not need encryption in this setting. $\endgroup$
    – Kai Elvin
    Commented Feb 12, 2014 at 8:54
  • $\begingroup$ @KaiElvin : $\:$ Is the client's public key used for anything other than such identification? $\;\;\;\;$ $\endgroup$
    – user991
    Commented Feb 12, 2014 at 8:56

2 Answers 2

Reset to default
1
$\begingroup$

Yes, it is possible to authenticate using ephemeral-static Diffie-Hellman. You would however first trust the public key of the static key pair. One way to do this would be to put it into a DH-based certificate, signed with a CA. It's not so common because usually certificates are used to establish trust, and certificates commonly use a public key used for signature generation when it comes to authentication. Of course you cannot use ECDH to sign/verify certificates, so you'd be stuck with a different algorithm to verify a certificate, if you decide to go that way.

After you've trusted the received public key you can perform normal DH-key agreement, then use the resulting session keys derived from the established secret to perform HMAC authentication. Within this authentication you would need to make sure that the ID's are used, that the nonces are random, that the public keys are included etc. etc. So generally we make it ourselves easy and lift the handshake procedure from an existing, known secure protocol, as indicated in the comments.

Improve this answer
$\endgroup$
5
  • $\begingroup$ It's not clear to me that the question is about authentication using an X25519 key; rather it seems to me that the question is about proving ownership of an X25519 key, without enough context to say how that figures into a protocol. $\endgroup$
    – Squeamish Ossifrage
    Commented Mar 12, 2019 at 15:49
  • $\begingroup$ That's fortunately covered by authentication. If you are able to derive the correct key using a static DH private key then you must control it. $\endgroup$
    – Maarten Bodewes ♦
    Commented Mar 12, 2019 at 19:24
  • $\begingroup$ If the context is that you're holding a one-on-one conversation, sure, but that's not necessarily the context. Maybe the author is thinking about third-party verifiability, which an X25519 key agreement doesn't enable. $\endgroup$
    – Squeamish Ossifrage
    Commented Mar 12, 2019 at 20:08
  • $\begingroup$ "The server wants to verify the client owns the associated private key." I don't see any unclarity in that statement, and the question mainly seems to turn around ECDSA vs ECDH. $\endgroup$
    – Maarten Bodewes ♦
    Commented Mar 12, 2019 at 21:09
  • $\begingroup$ ‘It is bound to a tcp connection’—doesn't tell me much. There's apparently something involving NaCl boxes here, but without a clearer notion of who the parties are and what they're trying to do in the face of what capabilities of an adversary, this question is not really answerable. Maybe it will turn out that static/static DH is what the asker wants, I don't know. Maybe DNSCurve or CurveCP or MinimaLT or Noise is what the asker wants, I don't know. $\endgroup$
    – Squeamish Ossifrage
    Commented Mar 12, 2019 at 21:12
0
$\begingroup$

You could use Schnorr Identity Scheme.

Client owns the Public key P where P = pG. and p is the private key

  1. Client generates nonce r and sends Server R where R = rG.

  2. Server sends client a random nonce e

  3. Client sends Server s = r + pe

  4. Server accepts if:

    sG = rG + epG = R + eP

Which is only possible if the client owns R and P

Improve this answer
$\endgroup$
1
  • $\begingroup$ This doesn't quite work because an X25519 key is only an x coordinate so you can't do addition as easily as that. You can share key material between Montgomery DH and EdDSA, but it takes a little more effort like XEdDSA. You can make a Montgomery-based signature scheme (or identification scheme), but it also takes a little more effort like qDSA. $\endgroup$
    – Squeamish Ossifrage
    Commented Mar 12, 2019 at 22:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.