I've run into an small issue regarding authentication between 2 services (One way communication) using public and private key authentication (Elliptic Curve, secp256k1).

The services will communicate via an API REST via HTTPS, and the proposed implementation would be to have the client sign something with it's private key, send the signature along with the rest of the data, in the authentication header, and the server verify that signature with the public key.

I've got a library to do the actual signing and verifying, so the actual cryptographic part of it is fine, and I know it's way more complex the alternatives (Just an API key, for example), but it doesn't bother me as long as the concept itself isn't flawed, and it's at least as secure as other (probably simpler) alternatives.

Is this a good idea? If not, Why? If it is, What exactly do I sign? Is anything good (Say, the current day)? Is there a problem in signing something static?

  • $\begingroup$ Generally you'd at least sign information that is linked with the session and particularly with session key establishment. But please study protocols such as TLS to get some idea. The time is less unique then you may think and is therefore not good; other's could try and establish a session at the same time and steal your signature - computers are really really really fast nowadays and relying on a clock is very very very dangerous. This is also why signing something static is no good, it allows for replay attacks. $\endgroup$
    – Maarten Bodewes
    Sep 3 at 17:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.