0

I'm attempting to setup client/server communication for an application via libsodium. So far I plan to distribute the application with a hard-coded public key. The server will keep its secret key without ever sharing it. This should let users encrypt messages and send them to the server, where the secret key decrypts messages.

In the event the secret key on the server is ever compromised (I'm not sure how, but just in case) how might one distribute new public keys to all clients? Is there a way to generate a new secret key without requiring distribution of new public keys? Something like:

make_new_secret( secret_buffer, previous_public );

I was hoping for a very simple solution that wouldn't require complicated algorithms for securely handing out new public keys. If making a new private key must be done while also making a new public key, what algorithms may be used to securely distribute public keys from server to clients?

Additional info (feel free to skip):

We can read here where Glenn Fiedler (author of libyojimbo, which uses libsodium) talks about the idea of "just roll a new private key".

If there is a way to re-use old public keys and create a new private key with libsodium, I would love to read about it. I have went through the docs and have yet to see any functions to do so. So I fear I may have to delve into more complicated algorithms for securely distributing new public keys.

I have checked out Diffie Hellman, but it seems to require both parties to start with a common "color". So I suppose my question is in regards to coming to a new agreed upon starting color.

Cecil
  • 135
  • 7

1 Answers1

0

The public/private keys are always pair (with the exception of EC having 2 public keys which is essentially the same thing). So if your server private key is compromised or you decide to roll it you need the client to know your servers new public key.

The challenge is real. If you hardcode it, then you have to recompile/redistribute application to your clients.

I don't understand your whole use case but if you are trying to do authorization, please look into OAUTH2 which will allow you to issue temporary (configurable on the server) tokens from your server to you client. In this case you can revoke OAUTH token in case either server or client is compromised and you (your server) has full control over it.

Zepplock
  • 28,655
  • 4
  • 35
  • 50
  • Okay, it's good to know this an actually challenging topic. My use case is a game released via Steam. So in this case it's actually not a problem to redistribute new binaries to users. So this makes sense! In my case I'm setting up a broker server for NAT-puncthrough, like a STUN server but with a custom protocol. – Cecil Nov 29 '16 at 22:08
  • To be clear: I'm just trying to secure the STUN-like server itself, and have been reading up on encryption. Anyway, thanks for the answer! – Cecil Nov 29 '16 at 22:19