Chinese National Cryptography (SM2/SM3/SM4/SM9/ZUC): A Developer's Introduction

What "Guomi" (国密) is

Chinese national cryptography (商用密码, "SM" = commercial secrets) is the set of algorithm standards published by the Chinese Cryptography Administration. It is not a new branch of cryptography — the algorithms rest on the same foundations as their international counterparts (elliptic curves, hashes, block ciphers) but are China-designed standards used for cryptographic self-sufficiency and compliance.

In day-to-day engineering, "adopt Guomi" usually means the SM2 + SM3 + SM4 trio. SM9 and ZUC show up in identity-based crypto and mobile-network stacks. For how GM/T, GB/T, ISO and RFC numbers relate, see Decoding the SM standard numbers.

What each algorithm does

Developers mostly meet the first three. Treating SM3 as "encryption" or using SM2 to encrypt bulk payloads are the two most common selection mistakes — the decision tree below blocks both.

Mapping to international algorithms

signing/encryption:  RSA, ECDSA  <->  SM2 (256-bit ECC)
digest:              SHA-256     <->  SM3 (256-bit output)
symmetric:           AES-128     <->  SM4 (128-bit block/key)
protocol suite:      TLS-RSA/AES <->  TLCP or RFC 8998 ShangMi suites

Strength equivalences (for intuition):

• SM2 256-bit ≈ RSA 3072-bit
• SM3 ≈ SHA-256
• SM4 ≈ AES-128

"Equivalent" means comparable security class, not interchangeable for compliance: if the checklist names SM3, SHA-256 will not pass acceptance even if it is strong.

Selection decision tree: role first, algorithm second

Pick the job, then the algorithm — do not start from a familiar name:

1. Reversible confidentiality (encrypt then decrypt)
   • Bulk / streaming data → SM4 (symmetric)
   • Short keys, tokens, or the outer wrap of hybrid encryption → SM2 public-key encryption (plaintexts should stay short)
2. Integrity fingerprint only → SM3 (no key, not reversible; not encryption)
3. Non-repudiation bound to identity → SM2 signatures (SM3 usually participates in the message digest construction)
4. Whole transport path must be Guomi → protocol layer (TLCP or ShangMi TLS), not "call each algorithm once inside a JSON body" — see Guomi HTTPS / TLCP with nginx

A typical Guomi API uses all three in one request: SM4 encrypts the body → SM3 digests → SM2 signs the digest. Integration and debugging order live in SM2/SM3/SM4 in practice.

Who uses it

1. Government: e-seals, e-licenses, government cloud (a web of GB/T standards assumes GM)
2. Finance: banking core migration, UnionPay standards, digital-currency work
3. 等保 2.0 (classified protection) level 3+: the most common driver — commercial cryptography becomes mandatory
4. SOEs / critical infrastructure: energy, transport, water
5. 密评 (crypto application security assessment): passing requires algorithm compliance

Consumer internet products usually have no hard Guomi mandate; the driver is contract language, sector rules, or MLPS / assessment clauses.

Two protocol paths: TLCP vs RFC 8998

"Guomi HTTPS" is often treated as one thing. It is two parallel tracks:

Keep algorithm-layer primitives (SM2/SM3/SM4 test vectors) separate from protocol-layer acceptance (handshake, certificates, suite negotiation). Passing a digest vector does not mean TLCP works. Deployment steps: Guomi TLS guide. Number decoder: standard numbers.

How developers implement it, by layer

Application layer (Java/Go/Node/frontend)

• Java: BouncyCastle (org.bouncycastle.crypto.engines) or hutool's SmUtil
• JS/Node: sm-crypto (pure JS, encrypt/decrypt/sign)
• Go: github.com/tjfoc/gmssl, github.com/emmansun/gmsm

Protocol layer (GM HTTPS)

Standard OpenSSL lacks GM TLS. Options:

• Tongsuo (formerly BabaSSL): Ant-open-sourced, OpenSSL-compatible syntax, GM-related capabilities and dual-certificate patterns
• GmSSL: Peking University's stack on the TLCP line
• Dual-certificate / dual-stack transition: SM2 certificates alongside an RSA/international stack, negotiated per client — common during migration

Hardware layer

Production key management requires certified crypto products: PCIe crypto cards, UKeys, cloud HSMs (GM editions from cloud vendors). Software implementations are for development and debugging — production signing keys should never leave certified hardware, a hard requirement of the assessment.

The algorithm selection matrix at the system level

• SM2 vs RSA/ECDSA: a like-for-like asymmetric replacement. SM2 keys are shorter, in a security class comparable to P-256 / RSA-3072 ranges; a Guomi name list decides whether RSA can remain.
• SM3 vs SHA-256: structurally similar digests under different standards. Without a mandate, follow the counterparty; with a name list, only SM3 counts. See SM3 vs SHA-256.
• SM4 vs AES: both 128-bit block ciphers. Library GCM support and hardware acceleration (AES-NI everywhere; SM4 instructions mainly on China-market chips) historically lagged AES — large retrofits often keep SM2/SM3 at the compliance boundary and AES inside for throughput. Whether that hybrid is allowed is a contract/assessment question, not a personal preference.

Recommended order: regulatory / contract name list → what the peer already implements (including mode) → then performance. Reversing that order is how teams finish coding before discovering "algorithm right, mode/certificate stack wrong."

Key management: where assessments are actually won

Algorithms are table stakes; keys decide. Findings cluster here: keys hardcoded in source, keys in broadly readable config files, keys never rotated, and signing-key generation on ordinary servers without certified products for regulated contexts. The remediation ladder: environment-injected secrets (days), centralized secrets management (weeks), certified cryptographic hardware for generation and storage (the regulated ceiling). Browser-minted test keys prove a flow; they do not prove compliance.

Learn by doing — with honest tool boundaries

One round-trip beats ten documentation reads. This site's GM toolkit runs in the browser (nothing uploaded) for learning, vector checks, and integration contrasts:

• SM2 Encrypt/Sign: keypair → encrypt → decrypt → sign → verify; ciphertext layout is C1C3C2 (GB/T 32918.4 recommended order). Legacy C1C2C3 peers will not interoperate until formats align.
• SM3 Hash Calculator: standard vector SM3("abc") = 66c7f0f4...; when digests disagree, check UTF-8 vs GBK and invisible characters first.
• SM4 Encrypt/Decrypt: ECB/CBC + PKCS#7. Good for key/mode/encoding checks; does not cover RFC 8998 SM4-GCM/CCM and cannot replace TLCP handshake debugging.

For the integration workflow when ciphertexts mismatch, see SM2/SM3/SM4 in practice.

Three FAQs

Q: Are GM algorithms actually secure, or "weakened domestic crypto"?
SM2/SM3/SM4 designs went through open international review (SM4 appears in the ShangMi TLS story around IETF RFC 8998). There are no practical structural breaks in the public literature. "GM = weak" is a misconception; real failures more often come from key handling, mode misuse (long-lived ECB in production), and misconfigured protocol stacks.

Q: Does my system have to adopt GM?
Two signals: 等保 level (3+ almost always means yes) and industry regulator (government/finance/SOE). Consumer internet generally has no mandate.

Q: How big is a migration?
Three tiers: algorithm-layer swaps (RSA→SM2 calls) are days; GM TLS (Tongsuo + GM certificates) are weeks; full assessment compliance (hardware + governance) is a months-long program.

Checklist

1. Know the trio: SM2 signs / encrypts short payloads, SM3 digests, SM4 encrypts symmetrically
2. Compliance test: 等保 level 3+ or government/finance → GM name list is likely
3. Separate algorithm layer from protocol layer: primitive vectors ≠ TLCP/ShangMi done
4. Fix test vectors in online tools before blaming business code (encoding, ciphertext order, mode/IV)
5. Production private keys live in certified products; software is for development
6. Prefer GB/T numbers in new docs; GM/T and GB/T are usually the same algorithm at different vintages

Triage notes

The decision tree orders by role first, algorithm second, explicitly to intercept the two most common drifts: treating SM3 as "encryption", and encrypting large payloads with SM2. The strength-equivalence table adds "does not mean interchangeable": when the compliance list names SM3, no amount of SHA-256 strength matches the acceptance check, hence the selection order — list first, peer implementation second, performance last. The protocol section keeps TLCP and RFC 8998 as separate tracks and stresses accepting the algorithm layer and the protocol layer independently — passing primitive vectors does not mean TLCP is compliant. The key-management section opens by deflating the idea: algorithms on paper are the entry ticket, and findings at cryptographic-evaluation time concentrate on keys.

Provided by ToolVault. Related tools: SM2 Encrypt/Sign, SM3 Hash, SM4 Encrypt/Decrypt. Related reading: SM standard numbers, Guomi HTTPS / TLCP, SM2/SM3/SM4 in practice, SM2 vs RSA, SM3 vs SHA-256. See the homepage for more developer tools.