API Encryption and Security Design: Combining Symmetric, Asymmetric, Hashing, and Signature Techniques

Background and Goal

With the rapid development of network technology, data security issues have become increasingly prominent. To prevent crawlers, request tampering, replay attacks, and to verify data integrity, this solution integrates HTTPS principles and WeChat Pay encryption design, using symmetric encryption, asymmetric encryption, and signature technologies to provide API interface encryption and decryption.

Solution Design

Symmetric Encryption, Asymmetric Encryption, Hash Algorithm, Signature Algorithm

Symmetric Encryption: Uses the same key for encryption and decryption, offering fast speed and low computational cost; the key must be securely transmitted.

Asymmetric Encryption: Uses a public‑private key pair; the public key encrypts data, the private key decrypts it. It secures key transmission but is slower, so it is mainly used to encrypt the symmetric key.

Hash Algorithm: Produces a fixed‑length digest regardless of input length; any change in the original data results in a completely different hash.

Signature Algorithm: Typically involves signing data with a private key and verifying the signature with the corresponding public key.

HTTPS Overview

Hypertext Transfer Protocol Secure (HTTPS) secures communication by using SSL/TLS to encrypt HTTP traffic and certificates for identity verification, ensuring data confidentiality and integrity.

WeChat Pay Encryption Principles

Request Signature: Each request is signed with the merchant API certificate private key using RSA‑SHA256; WeChat Pay verifies the signature.

Callback Verification: WeChat Pay signs each callback with its platform certificate private key; the merchant verifies using the platform public key.

Callback Decryption: The merchant decrypts encrypted callback data with the configured apiV3 key using AES‑256‑GCM.

Interface Encryption Design Ideas

Key Exchange: The client encrypts the symmetric key with the server’s public key and sends the ciphertext; the server decrypts it with its private key.

Data Encryption: The client encrypts request data with the symmetric key; the server decrypts with the same key.

Data Hash (Signature): Before sending, the client computes a hash of the data and includes the hash in the request; the server recomputes and compares to ensure integrity.

Data Validity Check: The client includes a timestamp; the server validates the timestamp to prevent replay attacks.

Technical Implementation

1. Key Generation and Management

Generate asymmetric key pairs with a tool; the server stores the private key securely. The client may periodically fetch the public key and store it locally (e.g., in LocalStorage ).

2. Encryption Algorithm Selection

Symmetric encryption uses AES; asymmetric encryption uses RSA. Hash algorithms include SHA‑256 and MD5; signature algorithms include RSA‑SHA256. Example code using Hutool library:

// Symmetric key
String key = "key";
AES aes = SecureUtil.aes(key.getBytes());
// Encryption
String ciphertext = aes.encryptBase64(content);
// Decryption
String result = aes.decryptStr(ciphertext);
// Asymmetric public key
String publicKey = "xxxxxxx";
RSA rsa = new RSA(null, publicKey);
// Encrypt symmetric key with public key
String ciphertextKey = rsa.encryptBase64(key, KeyType.PublicKey);
// Asymmetric private key
String privateKey = "xxxxxxx";
RSA rsa2 = new RSA(privateKey, null);
// Decrypt symmetric key with private key
String key = rsa2.encryptBase64(ciphertextKey, KeyType.PrivateKey);
// Hash example
Digester sha256 = new Digester(DigestAlgorithm.SHA256);
System.out.println(sha256.digestHex(data));
// Signature example
Sign privateSign = SecureUtil.sign(SignAlgorithm.SHA256withRSA, privateKey, null);
String sign = new String(Base64.getEncoder().encode(privateSign.sign(data)));
System.out.println("Signature: " + sign);
Sign publicSign = SecureUtil.sign(SignAlgorithm.SHA256withRSA, null, publicKey);
System.out.println(publicSign.verify(data.getBytes(), Base64.getDecoder().decode(sign.getBytes())));

3. Signature Rules

After encrypting queryString and body , concatenate queryString , timestamp, plaintext symmetric key, and body in order, then hash with SHA‑256 to obtain sign , which is placed in the request header.

4. Parameter Transmission

ek (encrypted‑key): Asymmetric‑encrypted symmetric key.

ts: Timestamp.

sign: Signature generated as described above.

The queryString is formatted as param1=value1&param2=value2 , then symmetrically encrypted to produce ciphertext=xxxxx and appended to the URL. The body is encrypted to a Base64 string and sent directly.

5. Backend Processing

Validate request timestamp from header.

Decrypt ek using the server’s private key to obtain the plaintext symmetric key.

Recreate the signature string (queryString + timestamp + symmetric key + body) and hash with SHA‑256; compare with the sign header.

Decrypt queryString and body using the symmetric key.

Encrypt the response data with the symmetric key and return the Base64 ciphertext.

Common Questions

Q: Why reference HTTPS in the design?

A: HTTPS combines symmetric and asymmetric encryption, offering high security while maintaining efficiency.

Q: What issues arise if only symmetric encryption is used?

A: The client environment is insecure; if the key is exposed, encryption becomes ineffective.

Q: What issues arise if only asymmetric encryption is used?

RSA cannot encrypt long texts (max 117 bytes).

Performance is much slower.

Q: Is signing still necessary when parameters are encrypted?

A: Yes, because not all interfaces are encrypted in production; signing prevents tampering and replay attacks.

Q: Why not use RSA‑SHA256 for signatures?

RSA‑SHA256 requires a private key for signing and a public key for verification.

The client only stores the public key; using RSA‑SHA256 would require an additional key pair, increasing maintenance cost.

We use SHA‑256 hashing with the plaintext symmetric key mixed in to simulate a signature.

Q: How to ensure security when the asymmetric public key is stored on the client?

Obfuscate and compress front‑end code.

Store the public key in encrypted, segmented form rather than plain text.

Even if the public key is leaked, the symmetric key is generated per request, preventing decryption of captured traffic.

Q: Does mixing symmetric and asymmetric encryption affect efficiency?

A: The actual data is encrypted symmetrically; asymmetric encryption only protects the symmetric key, so performance is comparable to pure symmetric encryption.

Q: Is this scheme absolutely secure?

No; if the client is compromised, an attacker can simulate legitimate requests.

Currently there is no absolutely secure solution for client‑side code.

Security Analysis

The scheme leverages the strengths of both symmetric and asymmetric encryption to ensure data confidentiality and high performance, while also addressing key security considerations:

Anti‑tampering: All request parameters are signed; without the client’s private key, modifications are detectable.

Anti‑crawler: Signed and encrypted requests prevent unauthorized automation; encrypted responses cannot be interpreted even if captured.

Anti‑replay: Timestamps are included in the signature and validated on the server; short‑term replay is mitigated, and longer‑term replay could be handled via server‑side caching.