Shulou(Shulou.com)06/01 Report--

The symmetrical and asymmetric algorithms are briefly talked about before, and the inverse process of asymmetry is the signature verification process. It is obvious that it takes a long time to decrypt the data because of the difference between the private key and the public key, so the third decryption and encryption scheme is the combination of the two. The idea is also very simple, that is, to make use of their respective strengths. As shown in the following figure:

Obviously, the symmetrically encrypted KEY is encrypted using asymmetric encryption, which not only avoids the asymmetric encryption of all data, but also solves the transmission problem of symmetrically encrypted KEY. This is the Session Key in the image above. Although the above figure solves the transmission problem of Session Key, it does not solve the problem. How to generate a Session Key? Of course, some people say I generate it at random. Of course, is there any way to generate a unique KEY? Of course, the only KEY can't be used here. But in the previous signing process, if the above idea is also used, I do not encrypt all the files, I only encrypt some of the files, and then can you prove that the original file must be mine? Obviously, a unique KEY is needed here, as shown in the following figure:

In the above signature authentication process, obviously I have to ensure that message digest and plaintext are one-to-one correspondence. So if this is done, there is obviously only one way, and that is the HASH algorithm. At present, there are two kinds of simple HASH, one is MD5, the other is SHA1. The principle of HASH algorithm is relatively simple, but there are some security risks. As shown in the following figure:

As shown in the figure above, the final size of the HASH result is fixed in both algorithms, one is 16 bytes and the other is 20 bytes, and the data size is not fixed, so it is obvious to imagine that even if there is an one-to-one correspondence, a fixed size HASH result can only correspond to a fixed amount of data, so if the number of data is unlimited, then HASH is bound to repeat. That's his flaw. But considering that the 128th power of 2 is also a large number, it is usually more reliable to use SHA1. As shown in the following figure:

I talked about the correspondence between the key and the public key in asymmetric encryption, so there is obviously one thing that is not clear, that is, the credibility of the public key. If the public key is not trusted, so is the decryption process. So how to ensure credibility?

This is not an algorithm to solve the trust problem, just like how to securely pass KEY in symmetric encryption. There must be a trusted channel. This channel is third-party notarization. The third party has a public public key that is known to everyone, but the third party encrypts the public key of the encrypted party. In this way, after the decryptor first unlocks the encrypted public key with a third-party public key, it can authenticate whether it is the corresponding trusted encrypted public key. In other words, the third party first issues a digital signature certificate with public key information for the encrypted party. As shown in the following figure:

This is commonly referred to as the CA certificate. Then considering that every individual or organization that wants to transmit information asymmetrically needs to get its own public key to this third-party authentication mechanism for private key encryption, then the activity cost is very high, so CA authentication is also managed hierarchically. As shown in the following figure:

Here, ROOT CA must first authenticate its subordinates. Then the user can trust the subordinate. This forms the concept of PKI framework on the market. We will not elaborate here, but from the above explanation, we can see that we do not trust each other by default in the process of data exchange, and it is precisely because we do not trust each other that multiple verification is needed to eliminate mistrust. From the technical implementation, it is generally impossible to achieve absolute security, so an organization with a certain degree of credibility is needed to act as a middleman. Considering that there is a lot of knowledge involved, such as the AAA mechanism, I won't go into details here, but why do I actually ramble on so many other things when the title is CURL operating GITHUP? This is because the above is the basis of security. At present, the most basic principles of IPSEC/SSH/SSL and other implementations are these two types, symmetric encryption and asymmetric encryption. Of course, most of them are the latter. The so-called Wancheng ignore its family, whether it is IPSEC/SSH/SSL/HTTPS/PGP is in the communication process to add encryption module for secure data transmission. So how do all these differences come true? First of all, let's look at SSL because HTTPS depends on SSL. So if you understand SSL, you understand HTTPS. SSL is a protocol, but let's guess first, based on what we learned earlier. First of all, we will definitely think that SSL will not use symmetric encryption algorithm, then it is asymmetric encryption algorithm, then asymmetric encryption, it is obvious that the need for public key exchange and encryption and decryption algorithms unified. So how do you trust each other? It is obviously a certificate, how to issue the certificate and how to verify it? This is what the SSL protocol defines, and because SSL has solved these security issues, it is very convenient to extend security to HTTPS based on HTTP. So first take a look at the SSL protocol stack as follows:

From the above, SSL is actually an application layer protocol, and because it is an application layer protocol, there is no need to modify the TCP/IP protocol stack at all, unlike IPSEC, which needs to modify the IP layer with the help of OS function. In other words, he transmits with the help of other protocols, only suggesting a tunnel transmission for these protocols. Usually includes the following four sub-protocols: handshake protocol, exchange cipher spec,alter protocol,record layer. Let's see how he implements this process, as shown in the following figure:

As can be seen from the above two figures, first, the server and the client configure the public key and certificate needed for SSL (because this is a two-way communication, so both parties need it), and the client chooses an encryption and decryption method to tell the server. The server can also confirm and then tell the client. When this process is over, a tunnel based on the application layer is built, for example, HTTP data can be transmitted through this tunnel. So how did HTTP become HTTPS? For example, how does a common APACHE server become HTTPS?

This is because APACHE has a SSL module plug-in. So far, the SSL protocol should be relatively clear, but there is another concept that is often confused, that is, SSLV2,SSLV3,SSLV3.1,TLSV1 PCT and so on. First of all, SSLV2,V3 is easy to understand the different versions of SSL, mainly to solve patent issues and some internal problems. PCT is implemented by Microsoft, SSL is implemented by NETSCAP, and now the most important implementation is OPENSSL. So what is TLSV1? It's actually SSLV3.1, but it's made by IETF. The aim is to combine the strengths of the two into a protocol that is not fully compatible with previous versions of SSL. The other WTLS is TLS on MOBILE, based on UDP.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.