The symmetric encryption method mentioned by @gaosboy is basically feasible. To enhance security, another simple solution is provided:
The server and the client first agree on a key K, and the client can encrypt and store K through tools such as SFHKeychainUtils;
When encrypting on the server side, you can get the current unix timestamp. Assuming it is T, you can use K-md5(T)-K (or any other rule, as long as T is confused into the key) during the encryption process. As the key, encrypt and pass the encryption timestamp T or md5(T) to the client;
After the client splices the key according to the corresponding rules, it decrypts it.
The advantage of this is that even if the key K or the key in any session is cracked, all sessions still cannot be completely decrypted. You must know K, the key splicing rules and the encryption method at the same time to completely crack .
I feel @yuanlizbyy’s solution is not reliable enough. The code and key are all on the client, so it's not difficult for those who really want to crack it. LZ thinks that the https handshake is too long-winded, so you can implement one yourself. It is much simpler. You only need to use a pair of public and private keys of RSA (or other asymmetric encryption systems). The client holds the public key and the server holds the private key.
Connection process:
1. The client generates a random key K (of course K needs to be strong enough), encrypts it with the public key, and then sends it to the server
2. The server uses the private key to decrypt and obtain K
3. The two directly use AES (key is K) to encrypt communication.
Advantages: safe (unless the server is invaded to obtain the private key, or the time-tested RSA/AES algorithm is cracked), fast (only the first round trip requires slightly slower RSA decryption).
Disadvantages: A handshake is required (but it can be solved: the round-trip handshake can actually be encrypted with the key K to send additional data).
I used to use symmetric encryption.
AES, the client maintains a private key, encrypts the data that needs to be encrypted and transmits it to the server through http, and then decrypts it
The symmetric encryption method mentioned by @gaosboy is basically feasible. To enhance security, another simple solution is provided:
The advantage of this is that even if the key K or the key in any session is cracked, all sessions still cannot be completely decrypted. You must know K, the key splicing rules and the encryption method at the same time to completely crack .
I feel @yuanlizbyy’s solution is not reliable enough. The code and key are all on the client, so it's not difficult for those who really want to crack it. LZ thinks that the https handshake is too long-winded, so you can implement one yourself. It is much simpler. You only need to use a pair of public and private keys of RSA (or other asymmetric encryption systems). The client holds the public key and the server holds the private key.
Connection process:
1. The client generates a random key K (of course K needs to be strong enough), encrypts it with the public key, and then sends it to the server
2. The server uses the private key to decrypt and obtain K
3. The two directly use AES (key is K) to encrypt communication.
Advantages: safe (unless the server is invaded to obtain the private key, or the time-tested RSA/AES algorithm is cracked), fast (only the first round trip requires slightly slower RSA decryption).
Disadvantages: A handshake is required (but it can be solved: the round-trip handshake can actually be encrypted with the key K to send additional data).
Welcome to buy bricks.
I used to use symmetric encryption.
AES, the client maintains a private key, encrypts the data that needs to be encrypted and transmits it to the server through http, and then decrypts it
@felix021’s solution is more reliable than @yuanlizbyy’s