As I send this question as a request to yahoo's server, the information in the request will be encrypted with yahoo's public key (which is available for everyone). Then the information will arrive at the server. There it will be decrypted with yahoo's server private key. Will Yahoo's server send me a response
after encrypting it with its private key?!? Can I then decrypt with its public key?!? I don't understand
that bit..it is not correct.. How will the server encrypt its response and how do I decrypt it?


Some clarification:

I get the public key of yahoo, encrypt a message, and send the information to yahoo. Yahoo decrypts
the information with its private key (this is the part that I understand). From Yahoo's response stage..
what happens? How does it encrypt its information so that the client side will know how to decrypt it?

  • 2
    You should probably look at How does SSL/TLS work?
    – RoraΖ
    May 5, 2015 at 15:34
  • I dont want to focus on SSL as much as I want to focus on the last concept of PKI, in which the server encrypts the information and sends it to the client that then decrypts it.
    – Kratos
    May 5, 2015 at 15:37
  • 2
    But that's the problem PKI (public key cryptography) is not being used for encryption or decryption at all. The keypair that the server owns is so that you can identify the server. The certificate is a digitally signed statement that the server is what it claims to be. Having the private key to its cert, it is the only thing that can respond correctly to a challenge to prove its identity.
    – Rob
    May 5, 2015 at 15:39
  • "I dont want to focus on SSL " ... Unfortunately, as @Rob said, the answer to your question is "SSL", PKI is not being used for encrypting your actual data. May 5, 2015 at 15:47

4 Answers 4


That's not quite what happens. As public/private key encryption is more expensive than symmetric encryption, its use is minimal. During the SSL handshake, the client and server agree upon a shared symmetric key that they use for bulk encryption. The remainder of the communication then occurs using this symmetric key. This symmetric key is then rotated on a regular basis to reduce the chances of an observer of the communication stream from guessing it.

  • So is it like this.. I get the public key of yahoo. Encrypt a message, send the information to yahoo. Yahoo decrypts the information with its private key (this is the part that I understand). From Yahoos response stage.. what happens? How does it encrypt its information so that the client side will know how to decrypt it?
    – Kratos
    May 5, 2015 at 15:34
  • 1
    It uses Diffie-Hellman (see answer by @Rob) to exchange the shared secret. The server's public/private key pair is only used for signing so that the client can confirm that the server holds the private key that matches the one in the SSL cert. May 5, 2015 at 15:37

You are not connecting to public web sites with a certificate of your own. The server does have a key pair in its certificate. Therefore, yahoo can't identify you; but you can identify yahoo. Setting up an encrypted link is actually unrelated to the certificates.

A simplified way to think of SSL is: 1) identification phase (certificates), then 2) key negotiation (ie: Diffie Hellman protocol), then 3) encrypted conversation.

Diffie Hellman is a way that two parties can exchange information in view of the whole world that results in them agreeing on a secret key that nobody else can figure out. It's just normal symmetric encryption with that key after that.


Your question is:

How does a single public key on the server allow messages to you be private and secure, without a HTTPS certificate on the client?

Good question. The answer lies in the mathematical fact that it's easy to raise a number to an exponent, but hard to factor a large number. You need to understand exponents and accept the fact some math is involved, and a very particular list of steps is needed to make this happen.

The name of this exchange of exponents and prime numbers is called the Diffie Hellman Key Exchange.

See the Wikipedia article below for a graphical explanation: http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange


Nobody else has made it explicit in a simple way yet, so I will do it:

1: You look at the certificate given by yahoo and confirm it matches the domain.

2: You perform a key exchange that is AUTHENTICATED using that keypair, for example it can be done through signing key exchange parameters. This confirms you're really talking to Yahoo and establishes a shared secret key.

3: Thanks to the secure key exchange algorithms, you now know that you share a secret key with Yahoo.

This is the crucial part - because you would reject connections not going to Yahoo, they can know that the SSL endpoint they see wants to connect to them (I'm ignoring sslstrip now for simplicity) as they keep the connection alive, and thus have confirmed they're talking to Yahoo as intended.

Therefore, when you send your request encrypted with your shared key to Yahoo they know it comes from a regular user (still assuming no sslstrip).

And when they send their response back encrypted with the shared key they therefore also knows it will be readable by that same user only.

Because nobody else knows the result of that previous key exchange.

You must log in to answer this question.

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