SM2 vs RSA: How to Choose Between Chinese and International Public-Key Crypto

The one-line answer

If you have Chinese compliance requirements (等保 classified protection, government, finance, SOEs) — SM2, no discussion. For pure technical choices both are secure: SM2 has shorter keys, RSA has a deeper ecosystem. In practice this is rarely an algorithm-quality question; it's a compliance question.

What they are

• RSA (1977): security rests on the hardness of integer factorization. The most widely deployed public-key algorithm — HTTPS certificates, SSH, JWT signing.
• SM2 (2010, national standard GB/T 32918-2016): a 256-bit elliptic-curve scheme from the Chinese Cryptocurrency Administration, security resting on the elliptic-curve discrete logarithm problem (ECDLP).

Head-to-head

Performance nuance: SM2 signs fast and verifies slowly; RSA is the reverse (verification benefits from the small exponent e=65537). Certificate-heavy flows (TLS handshakes) favor RSA verification; signing-heavy flows (IoT telemetry) favor SM2.

Three questions that decide it

1. Is there a compliance mandate?

等保 2.0 level 3+, government systems, regulated finance, SOE informatization — SM2 is mandatory (usually as the SM2/SM3/SM4 suite). Without a hard mandate, choose freely.

2. What does the other end speak?

The counterparty often decides: government platform integration requires SM2 certificates; international payment rails expect RSA. Transition periods commonly run dual certificates — one SM2, one RSA — negotiating per peer. Nginx with a GM fork (Tongsuo/BabaSSL) supports dual-certificate deployment.

3. Is key size sensitive?

In IoT/embedded, a 256-bit SM2 private key saves an order of magnitude in storage and bandwidth versus 3072-bit RSA, and signatures are ~70 bytes instead of 384 — meaningful on narrow-band networks.

The most common interop pitfall: C1C3C2 vs C1C2C3

An SM2 ciphertext has three parts: C1 (an EC point), C2 (the encrypted data), C3 (an SM3 digest). The old standard (GM/T 0003) orders them C1C2C3; the newer GB/T 32918.4-2016 recommends C1C3C2 — the two are incompatible, and this mismatch explains most interop failures:

• Java BouncyCastle defaults to C1C2C3 (switchable via parameter)
• The sm-crypto JS library takes a cipherMode flag (1 = C1C3C2)
• When the peer can't decrypt, confirm the ciphertext structure first

Use the online SM2 tool as a verified counterparty: generate a keypair, encrypt a known plaintext, and send the ciphertext to the peer — if it decrypts, your formats match.

Key format cheat sheet

SM2 public key:  130 hex chars (04 prefix + X 32B + Y 32B, uncompressed)
SM2 private key: 64 hex chars (32-byte scalar)

A compressed form (66 hex chars) exists too; some HSMs/UKeys emit it — convert during integration.

Migration notes (RSA → SM2)

1. Rebuild the certificate chain: SM2 certificates from a GM CA (CFCA, Shanghai CA, ...)
2. TLS stack: standard OpenSSL lacks GM TLS — use Tongsuo (formerly BabaSSL) or GmSSL
3. Data: existing RSA-encrypted data must be decrypted and re-encrypted — no in-place swap
4. Transition: run dual certificates for 3-6 months with gradual traffic shifting

Interop field guide: where each is supported

RSA: universal — every TLS stack, every HSM, every JOSE library, every legacy SOAP endpoint; the zero-interoperability-risk choice. SM2: first-class in Chinese ecosystems (Tongsuo, GmSSL, domestic HSMs, guomi browsers; Java via BouncyCastle; OpenSSL 3.x native SM2 support exists and improves yearly) and thin elsewhere — international JOSE libraries, cloud KMS services, and Western HSM lines mostly lack it. The interop matrix that matters for architecture: if your consumers include international parties, SM2-only signing locks them out — the pattern is dual-signature envelopes (SM2 for domestic compliance verification, ECDSA/RSA for international) at protocol boundaries, exactly as the guomi TLS guide runs dual certificates at the transport layer. The mistake to avoid: discovering interop gaps at integration week — the support matrix is a design-time input.

Performance: the numbers that surprise RSA veterans

SM2 signatures are faster than RSA-2048 signing (elliptic-curve advantage — SM2 sign ~2x faster than RSA sign on software), while SM2 verification is comparable to or slightly slower than RSA-2048 verify; both dominate RSA-4096 outright. Where RSA still wins: raw throughput on hardware-accelerated x86 (AES-NI-class acceleration for RSA via big-integer instructions is mature; SM2 acceleration depends on Chinese-market CPU generations). Net for most workloads: performance is a wash within 2x either way — the algorithm choice is decided by jurisdiction and interop, not speed. If someone argues SM2 (or RSA) adoption on performance grounds alone, the argument is missing the actual decision variables.

Checklist

1. Compliance mandate → SM2, done
2. Match the peer — and confirm C1C3C2 vs C1C2C3 first when debugging
3. Verification-heavy (TLS) favors RSA; signing-heavy (IoT) favors SM2
4. Migrate via dual certificates, never a hard cutover
5. Debug with the online SM2 tool to isolate the algorithm layer

Test vectors before integration week

Lock one short plaintext, one key pair, and the expected ciphertext/signature format (including C1C3C2 vs C1C2C3) in the repo. Round-trip it in the SM2 tool and in the peer library. If the hex matches locally but fails against the peer, you have a format or ID encoding issue — not a “Java vs Go crypto quality” debate. Keep RSA-2048 test vectors beside them when you ship dual envelopes so each path fails independently in CI.

Triage notes

The one-line answer compresses the decision into 'a compliance question, not an algorithm contest', and the three practical questions unfold from it: ask about the compliance mandate first, then what the other end speaks — the peer frequently decides the algorithm, and hybrid scenarios bridge with dual certificates in parallel. The comparison table deliberately splits sign and verify speeds in opposite directions (SM2 signs fast and verifies slowly, RSA exactly the reverse), matching two typical loads: TLS handshakes verify constantly, favoring RSA; IoT uplinks sign constantly, where SM2 saves resources. Only one interop pitfall is written up — the C1C3C2 versus C1C2C3 ciphertext order — for a stated reason: nine out of ten integration failures happen there.

Provided by ToolVault. Related tools: SM2 Encrypt/Sign, SM3 Hash, SM4 Encrypt/Decrypt, JWT Decoder. Related reading: Chinese cryptography guide, SM3 vs SHA-256. See the homepage for more developer tools.