GB/T 32907, GM/T 0004, RFC 8998: Decoding the Standard Numbers Behind SM2/SM3/SM4

The wall of numbers

The first time an integration requirement says "encrypt the payload with SM4 per GB/T 32907, sign with SM2, digest with SM3 per GM/T 0004, and support ShangMi TLS per RFC 8998", it reads like four unrelated documents. They are not — they are four vintages of the same three algorithms, and the numbers are easy to decode once you see the pattern.

The short version: GM/T numbers are industry standards from 2012, GB/T numbers are their 2016 national-standard elevations, ISO/IEC adoption came in 2017-2018, and RFC 8998 is the TLS 1.3 profile that binds all three algorithms together.

The decoder table

| Algorithm | Role | Industry standard (2012) | National standard (2016) | International | Tools | |---|---|---|---|---|---| | SM2 | Public-key: signatures, key exchange, encryption | GM/T 0003-2012 | GB/T 32918-2016 | ISO/IEC 14888-3 (signatures) | SM2 tool | | SM3 | Hash / digest, 256-bit | GM/T 0004-2012 | GB/T 32905-2016 | ISO/IEC 10118-3:2018 | SM3 tool | | SM4 | Block cipher, 128-bit | GM/T 0002-2012 | GB/T 32907-2016 | ISO/IEC 18033-3:2017 | SM4 tool |

Two habits worth forming when you read a Chinese crypto requirement:

1. Check the year suffix. A document citing "GM/T 0004-2012" and one citing "GB/T 32905-2016" are pointing at the same algorithm (SM3) through different vintages. If a vendor insists the two are different things, that is a red flag about the vendor, not about the standards.
2. Match the role to the family. "Digest" requirements always land on SM3, "signature or key exchange" on SM2, "data encryption" on SM4. If a requirement asks for SM2 encryption of bulk data, something got garbled in translation — SM2 is for short payloads and key transport, and bulk encryption belongs to SM4.

The elevation path, and why it matters commercially

Every SM algorithm followed the same route: published by the Chinese cryptographic authority in the mid-2000s (SM4 was declassified in 2006), formalized as an industry standard (GM/T, "密码行业标准") in 2012, elevated to a national standard (GB/T, "推荐性国家标准") in 2016, and then submitted into the corresponding ISO/IEC parts in 2017-2018.

The elevation is not paperwork — it changes which tenders can cite it. Procurement documents that once said "per GM/T 0002" were rewritten to "per GB/T 32907", and compliance checklists (MLPS grading, commercial cryptography application assessments) updated to the GB/T numbers. If you are building for the China market today, cite the GB/T numbers in your own documentation; the GM/T names still circulate in older specs and vendor datasheets, which is exactly why both appear in the wild.

RFC 8998: where the three meet TLS

In March 2021 the IETF published RFC 8998, defining the ShangMi (SM) cipher suites for TLS 1.3: TLS_SM4_GCM_SM3 and TLS_SM4_CCM_SM3. One suite line packs the whole family into its familiar TLS roles:

• Handshake signatures: SM2 (over the SM2 curve, with SM3 as its hash)
• Key schedule / transcript hashing: SM3
• Record encryption: SM4 in GCM or CCM mode (note: GCM/CCM, not the CBC mode most SM4 integrations start with)

This is the document behind "国密 HTTPS" gateways: a TLS 1.3 stack where every primitive is swapped for its SM counterpart, no AES or SHA-256 anywhere in the path. If a Chinese vendor asks whether your client "supports GM TLS" or "ShangMi suites", they are asking about RFC 8998 support — and if you need to inspect what such a gateway actually negotiates, a HAR capture of the handshake viewed in a HAR viewer shows the negotiated suite verbatim.

What each number will look like in your project

• Architecture doc: cites the GB/T numbers (32918 / 32905 / 32907) — cite them back.
• Vendor SDK datasheet: often still cites GM/T 0003/0004/0002 — same algorithms, older vintage.
• Compliance report: MLPS or 密评 paperwork — GB/T numbers plus the assessment framework itself (GM/T 0115 family for the assessment process).
• Gateway / TLS requirement: RFC 8998, usually phrased as "国密 SSL" or "GM/国密 TLS".

Verify before you build

All three algorithms can be exercised locally — no account, no upload — with the SM2 encrypt/decrypt/sign tool, the SM3 hash generator and the SM4 ECB/CBC tool. Before writing integration code, run one known test vector through each: it converts every format disagreement (hex vs base64, C1C3C2 ordering, PKCS#7 padding) from a two-day debugging session into a two-minute conversation with the counterparty.

For the deeper integration workflow — choosing between the algorithms, the debug order when ciphertexts mismatch, and the key-handling boundary — see the companion post SM2/SM3/SM4 in Practice.