Algorithms

China's SM2 and SM3: The Two Locks Every Gateway Request Must Pass

By 皮蛋小精灵 · Oct 28, 2026

Read original on juejin.cn ↗ Google Translate ↗ Alt translation

Western developers integrating with Chinese platforms (Alipay, WeChat Pay, government services) must handle SM2 and SM3 or fail at the gateway. Mixing up encryption and signing, or signing plaintext instead of ciphertext, blocks the request. Knowing the correct order and the serialization details saves hours of joint-debugging.

Summary

Chinese government and enterprise platforms require SM2 encryption and SM3 signing on every API request, but integration failures are common. SM2 is asymmetric encryption for confidentiality, SM3 is a one-way hash for integrity. They act like a safe and a tamper-evident seal: SM2's public key locks data, its private key unlocks; SM3 produces a fixed 64-character digest that the gateway recomputes to detect any alteration.

Common integration mistakes include signing plaintext instead of ciphertext, sorting parameters incorrectly, including null values or headers in the signature, mishandling the '04' prefix, and using the outdated C1C2C3 ciphertext order instead of C1C3C2. The correct sequence is non-negotiable: encrypt the payload first, then sign the resulting ciphertext. Gateways verify the signature before attempting decryption, so any other order fails immediately at verification. The article closes with a pragmatic debugging checklist for both "signature verification failed" and "decryption error" scenarios.

Takeaways

— SM3 is a one-way hash fixed at 256 bits (64 hex characters); it cannot be reversed and is used for integrity verification.

— SM2 is asymmetric encryption that uses a public key to encrypt and a private key to decrypt; it provides confidentiality.

— For SM3 signing, parameter names must be sorted by ASCII value before concatenation into the string to be signed.

— Null, undefined, and empty-string parameters are excluded from the signed string; including them breaks verification.

— HTTP headers and passthrough tokens are not part of the signature set unless the interface documentation explicitly says so.

— SM2 ciphertext typically starts with '04' (uncompressed elliptic curve point); decryption may require stripping or adding it.

— The current standard uses C1C3C2 ordering, not the older C1C2C3; a mismatch fails decryption even with correctly paired keys.

— The gateway verifies the signature before decrypting, so the payload must be encrypted first, then signed with SM3.

— When the gateway returns an error (404/500/token expired), it often sends plaintext JSON; blindly feeding that into SM2 decryption causes syntax errors.

Conclusions

Developers routinely confuse encryption with signing, but the two solve different problems: confidentiality versus integrity. That conceptual confusion, not the cryptographic math, causes most integration failures.

The 'encrypt then sign' order is not a style choice; gateways recompute the hash from the ciphertext and reject the request if the signature does not match the recomputed digest, so signing first is structurally impossible.

SM2 and SM3 follow international ECC and hash conventions, but the serialization details (the '04' prefix, C1C3C2 ordering) are where implementations diverge, making interoperability the real integration challenge.

Concepts & terms

SM2

Chinese national standard for asymmetric encryption based on elliptic curve cryptography (ECC). It uses a public key to encrypt and a private key to decrypt, similar to RSA but with shorter keys and smaller ciphertext.

SM3

Chinese national standard for cryptographic hash functions, equivalent to SHA-256. It outputs a fixed 256-bit digest and is used for integrity verification and signing.

C1C3C2

Ordering of SM2 ciphertext components: C1 (random elliptic curve point), C3 (digest of plaintext and point), C2 (actual ciphertext). This is the current standard, superseding the older C1C2C3 ordering.

Source: juejin.cn ↗ Google Translate ↗ Backup ↗