0

I have a query about public/private key encryption that I hope someone can answer. So as I understand it:

  1. Client connects to server and server responds with certificate
  2. Client pulls the public key from the certificate and encrypts using this
  3. Client sends message to server and server decrypts.

So that seems fine. What about when the server wants to send something back to the client machine that needs to be encrypted? What is the process to ensure that the server encrypts data in such a way that the client can decrypt it?

  • 1
    Are you talking about authorization using SSL-signed client certificates or the general private/public key behavior? – DarkLighting Nov 12 '15 at 14:32
  • They you asked your main question looks like general private/public key, but the rest of your explanation links to something like client authorization during a connection attempt. I just deleted my answer because the post from @StackzOfZtuff made me think that you haven't been much clear about your doubt. Please clarify. – DarkLighting Nov 12 '15 at 14:36
  • 1
    SSL signed certificates. – Robert Flook Nov 16 '15 at 15:06
2

Assuming HTTPS here.

Client connects to server and server responds with certificate

Yup.

Client pulls the public key from the certificate and encrypts using this

Nope. Client uses this to handshake with server. Result of handshake is a shared secret. That shared secret, called the Master Secret, is then split up into separate server-to-client and client-to-server keys.

Client sends message to server and server decrypts.

Yup. Client uses client-to-server key for that.

What about when the server wants to send something back to the client machine that needs to be encrypted?

The server uses the server-to-client key to encrypt. And the client uses that same key to decrypt.

  • OK, so if the handshake generates a shared secret, how is this generated? From a numerical point of view? – Robert Flook Nov 16 '15 at 15:03
  • Wait, I think I might be getting the gist. So the client sends a pre-master secret (using the public key) to the server and they use this in conjunction with their randomly generated numbers to generate a master secret. But if they both know the random numbers, and the client knows the pre-master secret, why doesnt the client just create the master key? – Robert Flook Nov 16 '15 at 15:26
  • Anti-replay. From a great article that was published by Tim Taubert yesterday: To protect against replay attacks the server must incorporate a server random into the master secret. That is unfortunately not possible before the first round-trip [...] More details there. – StackzOfZtuff Nov 17 '15 at 13:36
0

Its an exchange of keys, 2 sets of keys. the server sends a public to the client and the client sends a public to the server. though, talking about https an asymetric key is encrypted client side and decrypted server side this is then used for a secure pipe

  • But what happens if you don't have a public/private key? For example, I assume on my computer that I don't have a public/private key. So in this case how can the machine I am communicating with encrypt messages back to me? – Robert Flook Nov 16 '15 at 15:02
  • as mentioned, you send a message encrypted with the public key given to you by the server, this message holds an encryption key, the server will decrypt the key your computer has sent and use this key from now on to contact you, this key is now both the encryption and decryption key. the person above me explains this rather well. If i misunderstood then the only answer is you have no secure connection – TheHidden Nov 16 '15 at 15:07
  • Yes, sorry, misread your initial comment. The only question I now have is why there is a need for the pre-master key as opposed to just going straight to the calculation of the master key at the client end – Robert Flook Nov 16 '15 at 17:35

Your Answer

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

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