0

I'm writing my own tiny software license system and I'd like to establish a secure channel with a hybrid cryptosystem (asymmetric -> symmetric).

I'd like to avoid bringing the entire certificate thing up since my application (executable shipped to customers) would include my public key entirely. The problem is: how to verify the server's identity?

I thought of the following: I could have the server send the timestamp when the connection was first attempted encrypted with his private key (so the client app would be able to verify the server is really who claims it is).. but the timestamp could be imprecise due to unpredictable TCP/IP delays.

What could the server send that isn't vulnerable to a replay attack from a third malicious party?

Improve this question
7
  • "encrypted with his private key", that is not how public key encryption works.
    – mikeazo
    Sep 21, 2016 at 20:17
  • Do you own the server and your customers are connecting to your server with a client you ship to them?
    – mikeazo
    Sep 21, 2016 at 20:17
  • It feels like you are trying to build https - why not just use it? TLS1.2 is solid, there's the whole public key infrastructure already - give your server a real cert, the clients can verify its validity.
    – crovers
    Sep 21, 2016 at 20:28
  • @mikeazo correct.
    – user3834459
    Sep 21, 2016 at 20:33
  • @crovers isn't TLS overkill for this simple purpose?
    – user3834459
    Sep 21, 2016 at 20:33

1 Answer 1

Reset to default
1

If you can include a public key then you can also include a long-lived, self-signed certificate (which you can generate e.g. using the openssl command line tool). If you explicitly trust this certificate in the client then you can use a normal run-of-the-mill TLS or DTLS to create a secure connection with the server.

This way you would not require all the PKI, trusted third party etc., but still have an X509 certificate based hybrid solution.

Note that your certificate should be able to encrypt if you directly want to use RSA encryption for the session key and sign (authenticate) for the DHE or ECDHE schemes providing forward security.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .