One-time manual Implementation of ssl-simple encryption algorithm

One-time manual Implementation of ssl-simple encryption algorithm
Recently, LZ has got a job in the company and wants to publish some services to the company's partners. This kind of work LZ is easy to use and has already done countless servers. However, unlike the past, this service is to be published on the Internet, so it cannot be the same as the previous practice. Previous system interactions were between company intranets, so there was no data security problem. This time I had to consider data security, so LZ recently began to study various encryption algorithms. It took a total of three days before and after, and LZ finally completed the encryption layer. Although LZ does not know the principles of various encryption algorithms, it should be enough. After all, LZ does not calculate as an absolutely secure system (in fact, this is not possible), as long as it can block 90% of hackers. At the beginning of the Scheme Formulation, we must first develop a scheme. The protocol at the application layer adopts http, Which is definite. For encryption, LZ has two options. The first method is the traditional method. It uses a self-signed certificate and uses the ssl layer of jdk and web containers for implementation. This method is common and easy to use. The second method is manual programming, similar to writing a layer of ssl implementation. The principle is also very simple. The other party encrypts the data and sends it to the LZ server. After the LZ side decrypts the data, it will do what it should do. After the completion, it will encrypt the response data and send it to the client, what to do after the client decrypts the data. After some experiments and thinking, LZ decided to adopt the second method. The main reason is that this method is more flexible, and the encryption scheme is that LZ can be changed at Will (for example, replacing an algorithm with another algorithm ). Another reason is that what you write is easier to control. If there is a problem with the encryption layer, LZ can be used as a PM to locate the problem faster. The last reason is that it is easier to create clients in various languages based on algorithms rather than Java class libraries. The code design scheme is basically determined. The next step is code design. The code design is divided into the client and the server. As the client, LZ can provide public encryption and decryption components for partners to call (such as java client, php client,. NET client, etc ). As a server, LZ can easily encrypt and decrypt data by using filters and custom views. The client API is written as follows: HttpsHelper. sendJsonAndGetJson (JSONObject json); HttpsHelper. sendJsonAndGetJson (JSONObject json, int timeout); the above are the two methods published by the client component. The functions of the methods are well understood, and LZ won't talk much about them. In the implementation of the method, LZ has helped the client complete the encryption and decryption operations. Of course, the premise to use this client is to get the authorization code from LZ. The server requires a filter and a custom json view. SecurityFilter JsonView because LZ publishes restful services, the mvc framework is spring mvc. The specific codes of these two classes are not pasted here. In short, the filter decrypts the Request Parameters and the view encrypts the response results. The ssl layer has basically completed the design of the entire encryption and decryption function. The next step is to implement the work in the keystore. How can we choose the encryption algorithm? Previously, the LZ algorithm for encryption and decryption can be described as a big flaw. It knows an md5 algorithm, which is generally used for password encryption. This is hard to beat LZ, but it doesn't matter. There are Baidu and google. Is there anything you can't learn in a few days. After Baidu and google, LZ found that algorithms are mainly divided into the following three types: 1. irreversible encryption algorithms, such as md5, which are generally used for verification, for example, check whether the user password is correct. 2. symmetric encryption algorithm. This algorithm is reversible and has the same key on both sides. It can be used to encrypt and decrypt data and is generally used for encrypted data transmission. It features high speed, but low security compared with asymmetric encryption. 3. asymmetric encryption algorithms, which are still reversible and have different keys on both sides. One is called a public key and the other is called a private key. Both sides can also encrypt and decrypt data, it is generally used for digital signatures. It features low speed, but higher security than symmetric encryption. Previously, LZ heard that the implementation of ssl is a mix of several algorithms, which gives LZ great inspiration. Since each algorithm has its advantages, why don't we use them together. Therefore, LZ decided to use the md5 (irreversible encryption) + des (symmetric encryption) + rsa (asymmetric encryption) Encryption Method To Think About It (mainly in public vehicles and toilets, the encoding format can be Base64. Let's take a look at the requirements of LZ. There are two main points. 1. The client requires LZ authorization. That is to say, the Services released by LZ can be called only when they are not called. 2. Data is encrypted during transmission, and the security must be equivalent to the security of asymmetric encryption algorithms, but the performance must be equivalent to the speed of symmetric encryption. Let's take a look at whether the above algorithm can meet the needs. The process is like this. 1. Assume that LZ gives the client an authorization code, such as 123456. Assume that the data to be uploaded by the client is {"name": "xiaolongzuo "}. (Request data and response data are both in json format) 2. The client needs to encrypt 123456 with md5 and then put it into the transmitted data. That is, the transmitted data will become {"name": "xiaolongzuo", "verifyCode": "md5 (123456)"} 3. The client generates a random des key (note, symmetric keys are randomly generated every time). Assume It is abcdef. The client uses this key to encrypt the transmitted data using des and rsa to encrypt the random key. Finally, a json string is formed. That is, the final transmitted data will become {"privateKey": "rsa (abcdef)", "data": "des ({" name ":" xiaolongzuo "," verifyCode ": "md5 (123456)"}) "} 4, the server uses the opposite process to decrypt the data, and verifies whether the decrypted authorization code md5 (123456) exists. If not, the client is considered unauthorized. When the server returns data, it still uses abcdef to encrypt the data using des. Security Analysis: if the above data is intercepted by hackers, the primary task of hackers is to crack the private key of the rsa algorithm (the private key is only available in LZ, and the Public Key is included in the client component ), it is difficult to hear about this problem. The specific reason is that this is not what LZ needs to consider, and LZ does not yet have this capability. Based on this premise, LZ can think that the transmitted data is relatively safe. Performance analysis: because our rsa only encrypts the des private key with a short length, the slow speed of asymmetric encryption does not affect us too much. Almost all of the transmitted data is encrypted using des, so the speed is almost equivalent to the speed of symmetric encryption. Summary as the source code is owned by the company, it is not convenient for LZ to post it here, but the entire idea has been clearly stated here. Through this simple study, it is not difficult to find that learning with purpose is the most efficient learning. Imagine that if LZ is just idle, just look at the encryption algorithm, I believe it will not be clear in such a short period of time, and learn some basic usage methods. Therefore, it turns out that the best way to learn any knowledge is to use this knowledge for something.