In Wikipedia, as part of handshaking between a client and a server, the server send a public encryption key as part of the digital certificate. Then the client uses Diffie–Hellman key exchange to securely generate a random and unique session key for encryption and decryption. Questions:

  1. is the public key sent by server encrypted or clear? I assume it is clear since it is public
  2. How are the session key and public key related? Does the client sends session key to the server? session key sent: f(Random_gen_number, Public_key) where f is an encryption function?
  • Both questions have a "if you think about it" answer. So think about it and add your conclusion to the question so that we have something to answer rather than stating the obvious! Jun 3, 2018 at 22:52
  • Welcome on the Security SE! Things are going here a little bit differently as on the Wikipedia. If you have a question to an answerer, ask it from him in a comment below the answer. In the answers you are allowed to edit only what actually extends/improves the answer, new questions not.
    – peterh
    Jun 5, 2018 at 15:50

2 Answers 2


is the public key sent by server encrypted or clear? I assume it is clear since it is public

The public key of the server is contained in clear in the server certificate which is send in clear by the server, which means that the public key is implicitly send in clear too. Note that this is only the case with certificate based server authentication which is the most common way to authenticate the server in TLS but not the only one. Other ways to authenticate the server are for example pre-shared keys (PSK) where no public keys are involved at all.

How are the session key and public key related?

The result of the key exchange is a pre-master secret which then gets used to derive a master secret which then gets used to derive the session keys, i.e. the keys to encrypt and protect (HMAC) the application data.

If Diffie-Hellman key exchange is used as you state then there is no relation between the public key and the pre-master secret and thus not between the public key and the session keys. The only use of the certificate in this case is to authenticate the server and it plays no role in the key exchange. Diffie-Hellman key exchange can also be used for TLS handshakes where no public key is involved at all, for example with PSK authentication.

Does the client sends session key to the server? session key sent: f(Random_gen_number, Public_key) where f is an encryption function?

With Diffie-Hellman key exchange there is nothing even similar to this. With RSA key exchange the client instead creates the pre-master secret fully on the client side (i.e. it is not a result of a key exchange where both parties are involved, like in DH key exchange) and sends it to the server encrypted with the public key of the server. The server then decrypts this with its (secret) private key and thus can extract the pre-master secret. The process of deriving the master secret and the session keys from this is then the same as with DH key exchange.

This process of sending the pre-master secret to the server also means that knowledge of the servers private key allows to retrieve the pre-master secret, derive the session keys and decrypt all traffic. This is true even for older traffic if the traffic was captured at some time and the attacker or secret service got access to the private key only later. Contrary to this with DH key exchange no actual exchange of the pre-master secret happens but instead it is derived on both sides. Having access to the private key of the server will not allow an attacker to decrypt the sniffed traffic, i.e. an active and real-time man-in-the-middle attack is instead needed. That's why DH key exchange is the preferred one today and the only one support starting with TLS 1.3.

  • Thank you, how is the DH making the key exchange more secure? it is created by using the following: ((g^a) mod(p))^b mod(p) with primitive root mod p and congruence properties... however: g^b mod(p), g^a mod(p), g, and p are communicated over TLS. Cant someone in the middle deduct b then a? or pretend it is the server on a side and the client on b side? Jun 5, 2018 at 14:51
  • @josephcesana: Please don't ask new questions inside a comment - this is not a discussion forum here but a strict question and answer site. Also, questions regarding cryptographic details are better asked at Cryptography. And, to understand how DH provides security I recommend this video which very nicely explains the concepts behind DH. Jun 5, 2018 at 15:04
  • thank you again. Apologies, just start using it. Will follow instructions. j.c. Jun 5, 2018 at 15:17
  1. The public key is sent in the clear. It cannot be encrypted since the client and server have not been able to establish a shared secret yet. The shared secret will be generated as a result of the key exchange. Read more about the Diffie Hellman Key Exchange on Wikipedia

  2. The Diffie-Hellman key exchange will result in a shared secret. This is used to establish the master secret. The master secret is then used to generate encryption keys for the session. Read more about the master secret and the encryption keys in RFC 5246.

(P.S. The public key doesn't have to be in the certificate, Ephemeral Diffie-Hellman sends the key in a Key Exchange message.)

You must log in to answer this question.

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