Online SM2 public-key tool: generate keypairs, encrypt/decrypt (C1C3C2 per GB/T 32918.4-2016), sign and verify. SM2 is a 256-bit ECC scheme, the Chinese alternative to RSA. Local-only, private keys never leave your device.
TL;DR: SM2 public-key crypto: keypair generation, encrypt/decrypt (C1C3C2), sign/verify — ECC alternative to RSA.
For local tools, open DevTools → Network and search your input — it should not appear in requests.
Usage Guide
SM2 is the elliptic-curve asymmetric algorithm of the Chinese national cryptography family (the analogue of RSA), covering encrypt, decrypt, sign and verify. This tool generates key pairs and runs all four operations locally in the browser — the private key never leaves the machine. Built for fast test-key minting when integrating national-crypto interfaces.
1. How to use
- Generate an SM2 key pair first (public + private keys as hex strings).
- Confirm ciphertext order: default C1C3C2 (current standard); switch to C1C2C3 for legacy SDKs.
- Encrypt/decrypt: encrypt with the public key, decrypt with the private key.
- Sign/verify: sign with the private key, verify with the public key.
2. Typical uses
- National-crypto integration: mint test keys quickly to validate the flow against a spec from the counterparty.
- Learning elliptic-curve ops versus RSA: same public-encrypt / private-decrypt model, much shorter keys.
- Signature debugging: verifying locally isolates transmission issues — a match means the counterparty is signing wrong.
3. Key-safety boundary
The SM2 private key is a raw hex string; copying it to the clipboard moves it out of page control — fine for testing, but never paste a production private key into any web page, including this local-only one. This tool exists to mint usable test pairs and isolate integration bugs, not to manage production keys. Persist private keys in a key-management system with access control.
4. Ciphertext order and key formats (high-frequency interop)
- C1C3C2 vs C1C2C3: wrong order fails decrypt and looks like a bad key — toggle order on this page first.
- Public keys: 130-hex 04 uncompressed, bare 128-char XY (04 auto-prefixed), or 66-char 02/03 compressed; 0x/whitespace OK when pasting.
- Ciphertext prefix: some libraries wrap the whole blob with 04 — this tool strips it on decrypt.
- Signatures: ASN.1 DER output; raw r‖s (128 hex) from a peer needs conversion. Default userId 1234567812345678 must match both ends.
5. Which of the three SM algorithms to use
National-crypto retrofit is analogue replacement: SM2 for RSA (asymmetric — signatures, key exchange, public-key encryption), SM3 for SHA-256 (hashing), SM4 for AES-128 (symmetric data encryption). A typical national-crypto interface encrypts the payload with SM4, signs the digest with SM2, and produces that digest with SM3 — each algorithm plays its role in one request. When the counterparty spec is unclear, run test vectors of all three here first and take the matching combination into code.
6. Why integration and crypto-assessment work meets SM2
China MLPS level-3 and the commercial cryptography application security assessment (miping) mandate national algorithms for integrity protection of critical data — which lands on SM2 signatures at the API boundary. Retrofits in finance, government and energy most commonly add SM2 sign/verify to interfaces: the sender signs with the private key, the receiver verifies with the public key, and any in-flight tampering fails verification. Nine out of ten integration failures are the format issues above, not the algorithm — get signatures matching on this page before blaming business code.
7. Ciphertext order and protocol-layer boundary
Encryption defaults to C1C3C2 (GB/T 32918.4) with ASN.1 DER signatures; the page can switch to C1C2C3 for legacy SDKs — toggle order before second-guessing curve parameters. For the fuller interop checklist see [SM2/SM3/SM4 in practice](/en/blog/sm-crypto-practical-guide). This page also does not speak TLCP / Guomi TLS handshakes; see [Guomi HTTPS](/en/blog/guomi-tls-nginx-guide), the [standard-number decoder](/en/blog/sm-standard-numbers-explained), and the [Chinese cryptography guide](/en/blog/guomi-algorithms-guide).
FAQ
It stays local: the key pair is generated in the browser, and encryption, decryption, signing, and verification all happen on this page — handy for quickly minting test keys during integration. But the private key appears as plain hexadecimal, and copying it to the clipboard takes it out of the page's control. Production key generation, storage, and destruction belong in certified crypto modules or compliant libraries — never paste a production private key into any webpage, including this fully local one.
Three angles decide: strength — a 256-bit SM2 elliptic curve roughly equals 3072-bit RSA with far shorter keys; performance — SM2 signs small data faster while RSA verifies faster; compliance — Chinese national standards mandate SM2. The suite maps one-to-one: SM2 replaces RSA (signing, key exchange, public-key encryption), SM3 replaces SHA-256 (digests), SM4 replaces AES-128 (symmetric encryption). A typical SM interface encrypts the body with SM4, signs the SM3 digest with SM2, and each piece plays its part in one request.
Default is C1C3C2 per GB/T 32918.4-2016. The page offers a ciphertext-order switch for legacy C1C2C3 SDKs — the two orders don't interoperate, and a wrong order makes decryption fail in a way that looks like a key error, so align this first when integration stalls. Some libraries prefix the whole ciphertext with 04; decrypting here strips it automatically.
Uncompressed format = 04 prefix (1 byte) + X coordinate (32 bytes) + Y coordinate (32 bytes) = 65 bytes = 130 hex chars. You can also paste raw 128-char XY (04 is auto-prefixed) or a 66-char compressed key starting with 02/03, with or without 0x and whitespace. The private key is a 32-byte scalar (64 hex chars).
Nine times out of ten it's a format issue, not the algorithm: signatures output as ASN.1 DER, so a peer handing you raw r‖s (128 hex) needs conversion first; the userId defaults to 1234567812345678 and must match on both ends; a wrong ciphertext order also masquerades as a key error. Align the signature values on this page before digging into business code.
No. This page exercises application-layer SM2 primitives (encrypt/decrypt and sign/verify), not TLCP or ShangMi TLS handshakes. For the protocol layer and dual-certificate deployment, see the Guomi HTTPS deployment guide on this site.
Related Tools
Related Articles
SM2 vs RSA: How to Choose Between Chinese and International Public-Key Crypto
SM2 versus RSA compared: security strength (256-bit SM2 ≈ 3072-bit RSA), performance (signing vs verification tradeoffs), key sizes, the C1C3C2/C1C2C3 ciphertext format pitfall, Chinese compliance requirements, and how to verify with an online SM2 tool.
SM2/SM3/SM4 in Practice: Choosing, Integrating, and Debugging Chinese National Cryptography
A field guide to Chinese national crypto: SM4 vs SM3 vs SM2, plus the integration traps that dominate real work — C1C3C2 vs C1C2C3, hex vs Base64, CBC IVs — with browser-local tools for known-answer checks.
Chinese National Cryptography (SM2/SM3/SM4/SM9/ZUC): A Developer's Introduction
Introduction to China's commercial cryptography: what SM2, SM3, SM4, SM9 and ZUC each do, how they map to RSA/SHA/AES, a selection decision tree, TLCP vs RFC 8998 boundaries, compliance drivers, and what browser tools can and cannot verify.