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

After years of development,    information encryption technology has formed many mature applications by the combination of some basic algorithms, such as digital signature, security certificate, HTTPS, and the recent popularity of digital encryption currency, block chain and so on. These seemingly various applications are actually implemented by different combinations of three basic algorithms: data digest (also known as hash operation in many cases), symmetric encryption and asymmetric encryption. This paper puts aside the differences of these three kinds of algorithms in different implementation schemes, abstracts the commonness of all kinds of algorithms, and briefly describes the application scenarios of the three kinds of algorithms in the encryption system, so that developers can have a global understanding of the information encryption system in a short time, and can apply these three kinds of algorithms to the actual demand scenarios. I hope this paper can become a brief manual for designing information encryption applications.

   reading advice: each type of algorithm gives a function declaration in pseudocode, does not represent a specific algorithm, such as the function digest represents the actual use of MD5, SHA1, RIPEMD160 and other algorithms to achieve the data summary function, readers should not rush to consider the implementation of these functions in the reading process, but should understand the characteristics and functions of the algorithm. These algorithms are implemented in almost all mainstream programming language libraries, and there are few situations that need to be implemented on their own. For the readers who need to study the technical details, after reading this article, they can have an overall understanding of the tree of the information encryption system, and then follow the clues to study the leaves.

In   , we will introduce the characteristics and applications of these three kinds of algorithms, and then introduce the application of combining these algorithms.

1. Data Abstract 1.1. Function declaration: byte [] digest (byte [] data) 1. 2. Function properties:

   1.2.1. Regardless of the length of data, digest returns a certain length of data, usually dozens of bytes

   1.2.2. If digest (data1)! = digest (data2), then data1! = data2; if digest (data1) = digest (data2), it can be considered that there is a high probability of data1 = data2. In certain cases, for some algorithms, the probability of error is less than 1 / 128 ^ 2.

   1.2.3. The operation is irreversible, that is, you know the return value of digest, but you cannot deduce the value of data. By the way, people often talk about bitcoin mining, which refers to constantly trying to find a data so that the result of digest (data) is less than a certain number of difficulties. The basic code is as follows:

While (digest (blockData + random ()) > difficultyFactor); / / random () generates random numbers here

   shows that even in order to get a data value that meets a certain condition, it can only be tried violently, and there can be no other fast methods.

   1.2.4. The digest function is very fast compared to the other two types of algorithms to be discussed below. Note that it is relatively fast, because even so mining is a very time-consuming operation, hehe.

1.3. Application example: 1.3.1. Big data Retrieval comparison

   assumes that to do such a file upload system, it is required to check whether the same file already exists on the server before uploading the file, and if it already exists, it will not upload again. If there is no digest algorithm, you have to upload the entire file to the server for comparison, which is undoubtedly very time-consuming. If we do a summary operation on the file every time we upload the file (feature 1.2.4: the summary operation is very fast, it is ignored compared to the time it takes to upload the file), and save the summary value Then we do a summary operation on the file to be uploaded before the next upload, just submit the summary value to the server (feature 1.2.1: the summary value is usually only dozens of bytes). The server looks for the newly submitted summary value from the list of summary values previously saved by the client, and if it finds it (feature 1.2.2), it tells the client not to upload any more. This is the second upload technology used by many cloud disks, and many files on G are uploaded successfully in a few seconds, because other people have uploaded the same files before you.

1.3.2. Prevent data corruption

   is also an example of uploading files. Before uploading, the client sends the summary value of the local file to the server. After receiving the complete file, the server uses the same summary algorithm to calculate the summary value of the received file, and compares it with the summary value uploaded by the client. If the value is the same, the file can be considered complete; otherwise, the file is considered damaged in the transfer process (feature 1.2.2).

1.3.3. Prevent data falsification

   designs a simple recharge magnetic stripe card. All magnetic card machines can read the data in the card, but only authorized magnetic card machines can write data legally. The process of writing data is shown in the following figure:

The data written by    to the magnetic card is divided into two parts, one is plaintext data and the other is summary data. The summary data here has a term called signature. The signature generation process is very simple, that is, the password and plaintext data are stitched together as the input of the digest function, and the output of digest is the signature. When the authorized magnetic card machine reads the magnetic stripe data, it should first verify the signature, that is, read the plaintext data of the magnetic stripe into memory, then generate a signature with the password according to the same process as writing, and compare the signature with the signature recorded on the magnetic stripe. If the signature is the same, it is considered that the data has not been tampered with, otherwise it is considered to have been tampered with. Any modification of a byte on the magnetic stripe cannot go through the signature verification process. Because the unauthorized magnetic card machine does not know the password, it is difficult to generate a legal signature, although it can read the signature, it can not derive the password from the signature (feature 1.2.3).

   Note: in the actual production environment, in most cases, signing is done on the server side. In order to strengthen the security, a random number is added when the signature is generated, and the random number is written into the magnetic strip like plaintext, and participates in the signature verification process at the same time. At the same time, it can also perform multiple summary operations. These measures are designed to further make it more difficult to forge signatures by testing.

two。 Symmetric encryption 2.1. Function declaration: byte [] symEncrypt (byte [] plainData,byte [] password); byte [] symDecrypt (byte [] cipherData,byte [] password); 2.2. Function characteristics: 2.2.1. Encryption and decryption must use the same key. 2.2.2. It is faster than asymmetric encryption. 2.3. Application example: 2.3.1. File encryption and decryption

   will not repeat it.

3. Function statement: class KeyPair / / key pair {byte [] privateKey / / private key byte [] publicKey; / / public key}; KeyPair generateKeyPair (); / used to generate a key pair byte [] asyEncrypt (byte [] plainData,byte [] publicKey); / / encrypt data with public key byte [] asyDecrypt (byte [] cipherData,byte [] privateKey); / / decrypt data encrypted with public key 3.2. Function properties:

   3.2.1. Data encrypted with a public key can only be decrypted by the corresponding private key. That is, they are all in a key pair (KeyPair) generated by generateKeyPair. Sometimes it is encrypted with a private key and decrypted by a public key.

   3.2.2. Know a KeyPair publicKey, with the current computer computing power in the short term can not calculate its corresponding privateKey. This short term refers to at least a few decades.

   3.2.3. Asymmetric encryption is usually much slower than symmetric encryption. So it is usually only used to encrypt and decrypt keys or digests, not on long data.

3.3. Application examples:

   designs a file upload system that requires all the data uploaded by terminals to be encrypted. Even if the data passes through the eavesdropping network, the eavesdropper will not be able to know the data content. What happens if you use symmetric encryption:

1. All terminals and servers share a secret key, and if any terminal leaks the secret key, data transmission will no longer be secure.

two。 Each terminal is assigned a secret key, the server stores the secret key of each terminal, and the data from different terminals is decrypted using the secret key of the corresponding terminal. This can solve the problem of a terminal leakage, which leads to the leakage of the whole system. But there is also a risk of secret key disclosure.

At this point,    uses asymmetric encryption to solve all the above problems. First, a key pair (KeyPair) is generated with generateKeyPair, the publicKey of KeyPair is assigned to all terminals, and the privateKey of KeyPair is securely stored on the server. When uploading data, the terminal uses asyEncrypt (byte [] plainData,byte [] publicKey) to encrypt the data, and the server uses asyDecrypt (byte [] cipherData,byte [] privateKey) to decrypt the data. Because public key encrypted data can only be decrypted through the corresponding private key (feature 3.2.1), the data is secure even if it is eavesdropped on during propagation, and because of feature 3.2.2, even if everyone knows the public key, the private key is secure.

The above design scheme of    is only to demonstrate the use of asymmetric encryption scheme, which is generally not done in reality, because of feature 3.2.3, which can cause performance problems. So it is generally used in combination with symmetric encryption, and we will then introduce this usage.

4. The combined application of three kinds of algorithms: 4.1. Encrypted communication

   continues the example above, because the speed of asymmetric encryption is very slow, so we consider using it only to encrypt a temporary key with a small amount of data, and use this temporary key to encrypt the actual communication data using symmetric encryption. The process for the terminal to initiate communication to the server is roughly as follows:

1. The terminal generates a random password: symPassword.

two。 The terminal encrypts the random password using asymmetric encryption, which uses the public key (publicKey) corresponding to the server. AsyEncrypt (symPassword,publicKey) and send the encrypted result to the server.

3. The server uses the private key to decrypt asyDecrypt (encryptedSymPassword,privateKey) asymmetrically, and decrypts symPassword.

4. The terminal uses symEncrypt (data,symPassword) to encrypt the data and sends the encryption result to the server.

5. The server uses symDecrypt (encryptedData,symPassword) to decrypt the data.

   uses a temporary symmetric encrypted password for encrypted data transmission. Because the temporary password can be regenerated every time the communication is established, there is no risk of password disclosure.

4.2. Digital certificate

Another problem that has not been solved in    's encrypted communication above is how to distribute the public key of the server to many terminals. If you only use it on a small scale, such as in an office, you can use a flash drive to copy the server public key to each terminal computer. But if it is a public website and you want to communicate securely with all users around the world, how do you issue the public key of the server? Digital certificates are about to be used. Suppose we want to issue a certificate for a.com 's server, as shown in the following figure:

When the    terminal accesses the a.com, first download the digital certificate shown on the right side of the image above. General certificates are downloaded from a.com, but it is also safe to download them from other places because digital certificates are not used until they are verified. After the terminal gets the certificate, it begins to verify it, and the verification steps are as follows:

1. Perform a digest operation on the plaintext content of the lower part of the certificate in the above picture.

two。 Find and verify the public key of the certificate issuer locally according to the information of the certificate issuer in the plaintext. (this process will be detailed later)

3. With the public key of the issuer of the certificate, decrypt the digital signature part of the upper part of the certificate, and use asyDecrypt.

4. Compare the asyDecrypt result of step 3 with the digest result of step 1, and if the same, the certificate is considered legal; otherwise, the certificate is illegal or corrupted.

5. If the certificate is valid, you can use the public key of a.com in the plaintext content.

How exactly does step 2 of the previous step of    work? Notice that we are actually verifying the validity of the certificate issuer's public key, we need a certificate about the certificate issuer's public key:

   is linked together in this way, forming a thing called certificate chain. When will this cycle end? Always find a trusted certificate or root certificate. A root certificate is a certificate issued to itself by the certificate owner. How to verify the validity of the root certificate? The answer is no, we choose to trust it. Why do we trust it? because it is released with the operating system or browser.

   in practical applications, certificates also have the concept of expiration. This is also caused by the asymmetric encryption feature 3.2.2. To prevent an issuer's corresponding private key from being calculated from the issuer's public key after a long period of calculation.

4.3.HTTPS

   actually adds an encrypted communication protocol composed of 4.1 and 4.2 to the lower layer of the HTTP protocol. First, 4.2get the public key of the website, and then use the 4.1method to transfer HTTP data. The specific implementation is beyond the scope of this article.

4.4. Cryptocurrency and blockchain

   is nothing more than a combination of the three types of algorithms discussed in this article, and this topic will be discussed in the next article.

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.