I was watching this short video and apparently every time users open an HTTPS connection, a handshake between client & server happens. They interchange the public keys, keeping the private keys.

On each side, the public-private key pair is generated using an algorithm called RSA. Private key can't be derived from public key, nor open messages it itself encrypts.

I know this is just the surface.

Then, these keys are used to sign messages, that only the private key can open.

That's sort of easy.

But something in this process is called symmetric encryption, and something asymmetric, I just can't identify that.

Can you help me?

  • 1
    Simply put, If the algorithm uses same key for encryption and decryption it is symmetric; if the algorithm requires key pairs such as private key and public key, it is asymmetric encryption. Check this article related to PKI: en.wikipedia.org/wiki/Public-key_cryptography – Blacklion Dec 23 '20 at 20:46
  • what is pki @Blacklion public key i... – Minsky Dec 23 '20 at 21:06
  • @Blacklion but hey thanks a lot, that was crystal clear – Minsky Dec 23 '20 at 21:09

The underlying protocols used for HTTPS are SSL3, TLS1.0, TLS1.1, TLS1.2, etc. Each of these have a different way of exchanging keys, so there is not a one-size fits all answer to this question.

However, in symmetric encryption, the message is encrypted and decrypted using the same key. In asymmetric encryption, the message is encrypted using the public key, and the private key is used to decrypt the message.

But, in practice, a sender typically does not use the recipient's public key to encrypt a message (using asymmetric encryption) directly, because this takes a lot of computational resources. Instead, the sender generates a symmetric key on the fly, then this symmetric key is used to encrypt the message (using symmetric encryption). Then, the symmetric key is encrypted using the recipient's public key (using asymmetric encryption) and this encrypted symmetric key is sent to the recipient along with the encrypted message. On the receiving end, the recipient decrypts the encrypted key using his private key, then uses this key to decrypt the message.

See http://www.moserware.com/2009/06/first-few-milliseconds-of-https.html for an excellent walkthrough of how all of this works in TLS1.0. Even though this was written in 2009 and TLS1.0 has long been outdated at this point, you'll probably find this blog post to be very instructive if you're trying to get your head around these concepts for the first time. Once you're comfortable with this, have a look at https://tlseminar.github.io/first-few-milliseconds/, which is based on TLS1.2 (which uses a whole different method of key exchange, based on elliptical curves).

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.