Why can't I decrypt with the public key when I encrypt with the public key?

When you first came into contact with HTTPS, were you as confused as I was?

This thing has many complicated concepts, especially the public key and private key.

At that time, I really wanted to know why the public key could not be used to decrypt after encryption?

After reading this article, you will understand it and unlock many details in HTTPS.

Today, let’s start with symmetric encryption and asymmetric encryption.

Symmetric and asymmetric encryption

When you were in elementary school, did you pass a note around? When you passed a note around, every student who got it couldn't help but take a look at it. There was no privacy at all.

Suppose the class beauty wants to confess her love to me, but doesn’t want others to discover her affection in the process of spreading the message.

He would tell me during the ten minutes between classes, "Each letter moved one place to the left is what I want to say to you."

Then during class, he passed out a note with eb tib cj written on it. After reading it, every student who helped pass the note cursed inwardly, "Riddler, get out of Gotham."

Hehe, you don’t understand, but I do.

After I got the slip, I moved each letter one place to the left and got da sha bi.

What are you talking about? What are you talking about?

The bad woman wanted to destroy my heart for the Tao? I decisively rejected her confession.

Looking back now, I am moved and realize that this kind of thing, converting a piece of information that everyone can understand ( plaintext ) into another piece of information that no one can understand ( ciphertext ), is actually encryption .

This "left shift" encryption method is actually the so-called secret key. This form of encryption that uses the same secret key for both encryption and decryption is called symmetric encryption.

Symmetric encryption

Since there is symmetric encryption, there is asymmetric encryption.

The difference is that in asymmetric encryption, encryption and decryption do not use the same key, but two different keys, namely the public key and the private key.

Asymmetric encryption

The public key is responsible for encryption, and the private key is responsible for decryption. The public key is available to everyone, and the private key will never be disclosed. <br>.

So here comes the question.

Why can't I decrypt it using the public key when it was encrypted?

This actually involves the mathematical principles of public and private key encryption.

To put it simply, encryption is to convert a known number into another number according to certain rules. Previously, these numbers were readable when put together, but after such a conversion, they become unreadable.

In other words, the essence of encryption is num -> x (num is a known number, x is an unknown number).

For example, the addition and subtraction of one performed by the class beauty is a very simple conversion method.

Let's try a more complicated one, such as the remainder operation.

Suppose there is a remainder operation formula.

 5^2 mod 7 = 25 mod 7 = x

This formula is very simple. If we know 5 to the power of 2 and 7, we can easily get x=4.

But if we change the position of x.

 5^x mod 7 = 4

When we ask what value x is equal to, does the above equation hold true?

That would be much more troublesome.

 5 ^ 0 mod 7 = 1
 5 ^1 mod 7 = 5
 5 ^2 mod 7 = 4
 5 ^3 mod 7 = 6
 5 ^ 4 mod 7 = 2

Although it is a bit troublesome, we can still reverse the equation and find that it holds true when x=2.

But what if the above modular number becomes extremely huge?

 5 ^x mod 56374677648 = 4

At this time, the computer can only try them one by one to figure it out. A normal CPU would take many years to figure it out, so it can be considered impossible to figure it out.

In fact, the above formula is to encrypt 5 into 4. If x is known, it is easy to calculate the result on the right side of the equation is 4, but conversely, it is difficult to reversely deduce the value of x from 4. Therefore, this modulo algorithm is irreversible.

Although the modulo operation is irreversible, combined with Euler's theorem, this formula can become somewhat "reversible" under certain conditions (note that the quotation marks are added).

Let’s see how it’s done.

We break x into two halves, which becomes the product of p and q.

 Original ^ ( p * q ) mod N = Original

If p, q​, and N are selected correctly, the original text will return to the original text after a wave of modulo operations.

Knowing this is useless, but combined with Euler's theorem, and after some derivation processes that none of us can understand, the above formula can be transformed into the following.

 Original text ^ ( p ) mod N = ciphertext
 Ciphertext ^ ( q ) mod N = original text 

If you are interested in the calculation process combined with Euler's formula, you can check it out. But here it is enough to just know the conclusion.

In other words, knowing p​ allows encryption, and knowing q allows decryption.

Here p is the public key and q is the private key.

Ciphertext encrypted with a public key can only be decrypted with a private key. ​

Encryption and decryption formula

And what's even better is.

In fact, the positions of p and q in the formula are interchangeable, so it is also OK to say that "the ciphertext encrypted with the private key can only be decrypted with the public key". This operation is often called verifying a digital signature.

This is like the old costume TV dramas, where two long-lost relatives each carry a broken jade pendant. One day they find that the cracks in the two jade pendants can be put together, and they confirm that the other person is their long-lost eldest son.

These two pieces of broken jade have a bit of the flavor of public key and private key.

The relationship between public and private keys

It is enough for everyone to know this much about the principle.

Seeing this, we can answer the question in the title.

Why can't I decrypt with the public key when I encrypt with the public key? ​

Because the modulus operation of large numbers is irreversible , others cannot decrypt it by force. However, combined with Euler's theorem, we can select the appropriate p (public key), q (private key), and N (large number used for modulus), so that the originally irreversible operation becomes a little "reversible" under certain circumstances. Mathematical principles determine that the data we encrypt with the public key can only be decrypted by the private key. Conversely, the data encrypted with the private key can only be decrypted by the public key.

It can also be seen from mathematical principles that public key and private key encryption is safe, but the premise of this is based on the fact that "current computer computing speed is not fast enough". Therefore, if technology becomes more advanced one day and we become a higher-dimensional technological civilization, the current ciphertext may be no different from the plaintext.

Now that we understand symmetric encryption and asymmetric secrets, we can talk about the encryption principles of HTTPS.

How HTTPS works

If you are developing in the company's intranet and the code you write only provides services to the intranet, then it is likely that your service uses the HTTP protocol.

But if one day you want your friends on the external network to experience your service functions, you will need to expose the service to the external network. At this time, if you still use the HTTP protocol, the information sent and received will be in plain text. As long as someone catches a packet at any router in the communication link, they can see the content of your HTTP packet, so it is very unsafe.

In order to convert plain text into cipher text, we need to add a TLS layer on top of the HTTP layer for encryption. This is what we often call HTTPS.

TLS is actually divided into versions 1.2 and 1.3. The current mainstream version is 1.2. Let's take it as an example to see how the HTTPS connection is established.

HTTPS handshake process

The first step is to establish a TCP connection. After all, HTTP is an application layer protocol based on TCP.

After TCP successfully establishes the protocol, you can start the HTTPS encryption process.

In general, the entire encryption process is actually divided into two stages.

Two-stage encryption

The first stage is the TLS four-way handshake, which mainly uses the characteristics of asymmetric encryption to exchange various information and finally obtain a "session key".

The second stage is symmetric encrypted communication based on the "session key" of the first stage.

Let's first look at the first phase of the TLS four-way handshake.

HTTPS Process

First handshake :

• Client Hello: The client tells the server what encryption protocol version it supports, such as TLS1.2, what encryption suite it uses, such as the most common RSA, and also provides a client random number.

Second handshake :

•Server Hello: The server tells the client the server random number + server certificate + determined encryption protocol version (for example, TLS1.2).

The third handshake :

•Client Key Exchange: At this time, the client generates a random number called pre_master_key. It takes the server public key from the server certificate of the second handshake, encrypts pre_master_key with the public key, and sends it to the server.

•Change Cipher Spec: The client already has three random numbers: client random number, server random number and pre_master_key. These three random numbers are used to calculate a "session key". At this time, the client notifies the server that this session key will be used for symmetric confidential communication later.

•Encrypted Handshake Message: The client will generate a summary of the communication data content so far, encrypt it with the "session key", and send it to the server for verification. At this time, the handshake process on the client side is completed, so it is also called a Finished message.

Fourth handshake :

•Change Cipher Spec: The server receives the pre_master_key from the client (although it has been encrypted by the server's public key, the server has a private key and can decrypt it to get the original text), collects three random numbers, and uses the same algorithm as the client to get a "session key". At this point, the server tells the client that it will use this "session key" for encrypted communication.

•Encrypted Handshake Message: Same as the client operation, a summary of the communication data so far is generated, encrypted with the "session key", and sent to the client for verification. At this point, the handshake process on the server is also completed, so this is also called a Finished message.

Just a few handshakes, full of details, no one is superfluous.

Let’s explain them one by one.

Because everyone must be confused, I will try to explain the following questions in brief sentences.

Is HTTPS symmetric encryption or asymmetric confidentiality?

The four-way handshake in the early stage is essentially using the characteristics of asymmetric encryption to exchange three random numbers.

The purpose is to use these three random numbers to generate a symmetric encrypted session key. Later, symmetric confidentiality was used for communication.

Symmetric or asymmetric encryption

Why not just use asymmetric encryption for everything?

Because asymmetric encryption is slow, symmetric encryption is relatively fast.

What is the server certificate in the second handshake? How do I get the public key from it?

A server certificate is essentially a server public key encrypted by the private key of an authoritative digital certificate authority (CA).

What is a server certificate?

As mentioned above, data encrypted by a private key can be decrypted using a public key. And the public key is available to anyone. So during the second handshake, the client can use the CA's public key to decrypt the server certificate and get the server's public key hidden inside. ​

Decrypt the certificate using the CA public key

Does it seem a bit redundant?

So here comes the question.

Why can't I just send the public key, but have to encrypt it with the CA's private key before sending it?

On the other hand, if only the public key is transmitted, the public key may be replaced by the hacker during the transmission process. Then during the third handshake, the client will use the fake public key to encrypt the third random number pre_master_key​, and the hacker will naturally know the most critical pre_master_key after decryption. And because the first and second random numbers are public, the "session key" can be calculated.

Therefore, there needs to be a way to prove that the public key obtained by the client is the real server public key, so the CA's private key is used to encrypt it into a server certificate. In this way, the client can use the CA's public key to decrypt it and verify whether it is the real server public key.

Then the problem comes again

How to obtain the CA's public key?

The easiest thing to think of is to request the CA's official website to obtain the public key. However, with so many people around the world going online, if they all request the CA's official website, the official website will definitely not be able to handle it.

Considering that there are not many CA organizations that can issue certificates, there are not many corresponding CA public keys. Putting them directly as configuration in the operating system or browser will perfectly solve the above problem.

The CA public key is built into the operating system or browser

No one else can get your three random numbers?

Of these three random numbers, two come from the client and one comes from the server. The client random number and the server random number in the first and second handshakes are both in plain text. Anyone can get them if they are willing.

But the third random number pre_master_key cannot work, because it is encrypted by the server's public key after it is generated by the client and before it is sent to the server, so only the server itself can decrypt it with the private key. Even if someone else gets it, without the server's private key, they cannot decrypt the original text.

Encryption and decryption of pre_master_key

Why three random numbers? And not just one or two?

Three random numbers generate a symmetric key

It seems that the third random number pre_master_key is the key, and the other two seem dispensable?

Indeed, even without the other two, the encryption function is not affected. The reason why two random numbers are needed is that the randomness of a single pre_master_key is insufficient, and the keys that come out of multiple random numbers may be the same. However, if two more random numbers are introduced, the randomness of the "session key" can be greatly increased, thereby ensuring that the session key used for each HTTPS communication is different.

Why do we need to give a summary for the third and fourth handshakes?

At the end of the third and fourth handshakes, there is a Finished message containing a summary.

In summary, to put it simply, it is a hash operation on a large piece of text. The purpose is to confirm that the data has not been tampered with during the communication process.

In the third handshake, the client generates a summary and the server verifies it. If the verification is successful, it means that the data generated by the client has not been tampered with, and the server can communicate with the client with confidence.

The fourth handshake is the other way around. The server generates a summary and the client verifies it. If the verification is successful, it means that the server is trustworthy.

So here comes the question again.

Why do we need to hash once instead of comparing directly with the original text?

This is because the original text is too long, and hashing can make the data shorter. Shorter means lower transmission costs.

Digest Algorithm

How many pairs of private keys and public keys are involved in this process?

Two pairs.

​The server's own public key and private key: In the second handshake, the server sends its own public key (hidden in the digital certificate) to the client. In the third handshake, the server uses the server's public key to encrypt the third random number pre_master_key. After receiving it, the server uses its own private key to decrypt it.

CA's public and private keys: In the second handshake, the digital certificate transmitted contains the server's public key encrypted by the CA's private key. After the client receives it, it will use the CA public key built into the operating system or browser to decrypt it.

Summarize

• Modulo operations of large numbers are irreversible, so others cannot decrypt them by force. However, combined with Euler's theorem, we can select the appropriate p (public key), q (private key), and N (large number used for modulo operations), so that the originally irreversible operations become a little "reversible" under certain circumstances. Mathematical principles determine that data encrypted with a public key can only be decrypted with a private key. Conversely, data encrypted with a private key can only be decrypted with a public key.
• HTTPS is equivalent to HTTP+TLS. The current mainstream is TLS1.2, which is based on the TCP three-way handshake and then the TLS four-way handshake.
• The TLS four-way handshake process involves two pairs of private keys and public keys, namely the server's own private key and public key, and the CA's private key and public key.
• The TLS four-way handshake can be difficult to memorize. I suggest you focus on the flow of three random numbers, use this as a basis for understanding, and you will probably be able to remember it.