SM9 Identity-Based Cryptography (IBC)

SM9 is the identity-based member of the Chinese SM suite: any string — an email address, a phone number, a device serial — works directly as a public key, and a Key Generation Centre issues the matching private keys. This is a read-only explanation page: how IBE and IBS work step by step, how identity-based crypto compares with PKI certificates, and the official curve parameters.
Calculator planned. A browser-side SM9 calculator is on the crypto family roadmap — the pairing machinery (Fp12 extension-field tower, Miller loop, final exponentiation) is a kernel of its own. Meanwhile the sibling pages compute SM2, SM3 and SM4 fully in your browser.
What is SM9?
In one sentence: SM9 is the Chinese national standard for identity-based cryptography (GB/T 38635.1/.2-2020, successor of the GM/T 0044-2016 series): the public key is an identity string such as bob@example.com, the matching private key is issued by a trusted Key Generation Centre (KGC), and the mathematics that makes this work is a bilinear pairing on a 256-bit BN curve.

Conventional public-key crypto (RSA, SM2, ECC) answers the question "is this really Bob's key?" with certificates: a CA hierarchy vouches that a certain random-looking key blob belongs to Bob. Identity-based cryptography flips this around: the name itself is the key material. Anyone who knows Bob's email address can encrypt to him or verify his signatures without fetching anything — no certificate directory, no trust-chain validation. The price is a trusted third party that can derive every private key, and much heavier mathematics. SM9 is the standardised Chinese instantiation of that trade.

The cast: who holds what
RoleWhat it is
Identity (ID)Any byte string, e.g. bob@example.com, used directly as the public key. It must be canonical: byte-exact, no two spellings of the same person.
KGCKey Generation Centre: holds the master private key, verifies who an identity belongs to, and issues the matching user private key.
Master key pairsTwo independent pairs: signing (secret ks, public Ppub-s = [ks]P2) and encryption (secret ke, public Ppub-e = [ke]P1). Note the deliberate asymmetry: one master public lives in G2, the other in G1.
User private keyA point on the curve, derived from the ID by the KGC. Signing key dsA lives in G1; decryption key deB lives in G2.
hidA one-byte function identifier mixed into every key derivation, so one identity yields cryptographically independent keys for signing, encryption and key exchange.
H1, H2, KDFSM3-based auxiliary functions (GB/T 32905): hash-to-integer mappings and the key-derivation function.
Pairing eThe R-ate bilinear pairing e: G1 × G2 → GT over the 256-bit BN curve defined below. The algebraic engine of the whole scheme.
How SM9 identity-based encryption (IBE) works

Alice wants to send a secret to bob@example.com — possibly before Bob has ever enrolled with the KGC:

1. Alice derives Bob's public key herself: QB = [H1(IDB ‖ hid, N)]P1 + Ppub-e. No directory lookup, no certificate fetch — the identity string and the public master key are all she needs.
2. Ephemeral: random r; compute the point C1 = [r]QB.
3. Pairing: g = e(Ppub-e, P2), then w = gr.
4. Keys: K = KDF(C1 ‖ w ‖ IDB, klen) (SM3-based), split into K1 (wrapping key) and K2 (MAC key).
5. Mask: C2 = the message XORed with (or encrypted under) K1; C3 = MAC(K2, C2). The ciphertext bundles C1, C3 and C2.
6. Bob, whenever he enrolls: the KGC verifies he really is bob@example.com and issues deB = [ke·(H1(IDB ‖ hid, N) + ke)-1]P2. He then computes w′ = e(C1, deB), rebuilds the same K, checks the MAC and unmasks the message.

Why it works: by bilinearity, e(C1, deB) = e([r(H1+ke)]P1, [ke/(H1+ke)]P2) = e(P1, P2)r·ke = w — exactly the value Alice folded into the KDF. The elegant part is step 6: encryption needs no prior enrolment. Alice can seal a message today; Bob can only open it after proving the identity to the KGC. Deferred key generation is the signature feature of IBE.

How SM9 identity-based signatures (IBS) work

Alice signs a message M with her signing key dsA:

1. g = e(P1, Ppub-s); random r; w = gr.
2. h = H2(M ‖ w, N); l = (r − h) mod N (retry with a fresh r if l = 0).
3. S = [l]dsA. The signature is the pair (h, S).

Anyone who knows Alice's identity verifies it without any certificate:

4. P = [H1(IDA ‖ hid, N)]P2 + Ppub-s; u = e(S, P); w′ = u · gh.
5. The signature is valid exactly when H2(M ‖ w′, N) = h.

Again bilinearity closes the loop: u = e(P1,P2)l·ks and gh = e(P1,P2)ks·h, so w′ = e(P1,P2)ks·(l+h) = e(P1,P2)ks·r = w.

Identity-based vs certificate-based (IBE vs PKI)

This is the decision that actually matters when choosing SM9. Both worlds give you public-key encryption and signatures; they differ in where the trust lives:

PKI / certificates (SM2, RSA world)Identity-based (SM9)
Public key of bob@…A 65+ byte blob inside a certificate, fetched from a directory or the recipient himselfThe string bob@example.com itself; the verifier computes the key from it
Trust rootA CA hierarchy; every chain must validate up to a rootOne KGC master public key for the whole domain
Encrypt before the recipient has a key?No — you need his valid certificate firstYes — encrypt now; he enrolls and decrypts later
Private key generated byThe user's own machine or device (often never leaves it)The KGC, centrally, from the identity
Key escrowNone by designInherent: the KGC can derive every user's private key
RevocationCRLs / OCSP per certificateNo equivalent; usual practice embeds validity windows in the ID (e.g. bob@example.com|2026) so keys expire by construction
Cost per operationPlain ECC arithmetic — fastA bilinear pairing — orders of magnitude slower than a scalar multiplication
StandardsX.509 / RFC 5280; SM2 under GB/T 32918GB/T 38635.1/.2-2020 (formerly GM/T 0044-2016)
Natural habitatOpen internet: TLS, code signing, general PKIClosed ecosystems: one bank's messaging, one agency's email, fleet/device identity — where a central authority is acceptable and enrolment-free encryption pays off

Rule of thumb: SM9 buys you certificate-free key management at the price of key escrow and slower math. If you cannot accept a third party that can read everything or forge anyone, stay with SM2 certificates; if enrolment-free encryption inside one organisation is the goal, SM9 is exactly that tool.

SM9 system parameters (official 256-bit BN curve)

The parameter set from GB/T 38635.1-2020 (also in GM/T 0044.5-2017). These are read-only reference values — the self-test below re-checks every constant on this page against independently verified values:

ItemValue
CurveBarreto–Naehrig (BN) curve E: y2 = x3 + b over Fp, b = 05
Curve parameter t60000000 0058F98A
Field prime pB6400000 02A3A6F1 D603AB4F F58EC745 21F2934B 1A7AEEDB E56F9B27 E351457D
Group order NB6400000 02A3A6F1 D603AB4F F58EC744 49F2934B 18EA8BEE E56EE19C D69ECF25
Parametrisationp = 36t4 + 36t3 + 24t2 + 6t + 1; N = 36t4 + 36t3 + 18t2 + 6t + 1
Cofactor1
Embedding degree k12 (field tower Fp → Fp2 → Fp4 → Fp12)
PairingR-ate pairing e: G1 × G2 → GT, all three groups of order N
G1 generator P1 (on E)x = 93DE051D 62BF718F F5ED0704 487D01D6 E1E40869 09DC3280 E8C4E481 7C66DDDD
y = 21FE8DDA 4F21E607 63106512 5C395BBC 1C1C00CB FA602435 0C464CD7 0A3EA616
G2 generator P2 (on the twist E′: y2 = x3 + 5·u over Fp2, u2 = −2)xc0 = 37227552 92130B08 D2AAB97F D34EC120 EE265948 D19C17AB F9B7213B AF82D65B
xc1 = 85AEF3D0 78640C98 597B6027 B441A01F F1DD2C19 0F5E93C4 54806C11 D8806141
yc0 = A7CF28D5 19BE3DA6 5F317015 3D278FF2 47EFBA98 A71A0811 6215BBA5 C999A7C7
yc1 = 17509B09 2E845C12 66BA0D26 2CBEE6ED 0736A96F A347C8BD 856DC76B 84EBEB96
(Fp2 elements written c0 + c1·u)
Hash / KDFH1, H2 and the KDF are built on SM3 (GB/T 32905-2016); hid is a one-byte function identifier chosen by the KGC
Where SM9 sits inside the SM suite
  • SM9 (this page) — the key-management disruptor: identities instead of certificates, KGC instead of CA hierarchy.
  • SM3 — the hash; SM9's H1/H2/KDF are built on it. Compute digests on the SM3 page.
  • SM4 — the block cipher that typically encrypts the bulk data under the key SM9's KDF produces. Try it on the SM4 page.
  • SM2 — the certificate-world counterpart: same jobs (sign, encrypt) with ordinary ECC and a PKI behind it. Full calculator on the SM2 page.
Compliance note: SM9 is a suite-independence and key-management choice for regulated Chinese deployments, comparable in strength to other ~128-bit systems. Production roll-outs must treat the KGC master key as the crown jewel — typically held in an HSM, split across several trustees, or both.
Common misconceptions
  • "The identity is the public key, so anyone can decrypt my mail." No — anyone can encrypt to the identity and verify signatures from it; only the holder of the KGC-issued private key can decrypt or sign. The KGC checks who Bob really is before handing out deB.
  • Ignoring key escrow. A compromised KGC master key means the attacker can silently derive every user's private key — total decryption and total impersonation for the domain. This is by design (that is how identity-based crypto works), not a flaw to patch. Mitigate operationally: HSM, threshold KGC split across entities, strict issuance audit logs.
  • Assuming the identity string is forgiving. It is hashed byte-exact: Bob@Example.COM, bob@example.com and " bob@example.com" are three different public keys with three different private keys. Freeze one canonical format before deployment — and consider appending a validity window for revocation.
  • "256-bit curve, so 256-bit security." Pairing-based crypto does not scale like plain ECC: attacks work in the huge Fp12/Fp6 fields where index-calculus (sub-exponential) algorithms apply. Published analyses put 256-bit BN curves around the ~100–128-bit security class, and researchers have proposed larger BN parameters for SM9 (e.g. "Searching BN Curves for SM9", 2019). Treat SM9 as roughly AES-128 class — solid, but not a 256-bit fortress.
  • Expecting it in OpenSSL. OpenSSL implements SM2/SM3/SM4 but has no SM9. Working open-source stacks include GmSSL and Bouncy Castle.
FAQ

Is SM9 a Chinese invention? The concept is not: Shamir proposed identity-based crypto in 1984, and Boneh–Franklin (2001) built the first practical pairing-based IBE. SM9 (GM/T 0044-2016, then GB/T 38635.1/.2-2020) is China's national-standard instantiation of that lineage.

Why is there no SM9 calculator on this page? Unlike SM2/SM3/SM4, SM9 needs a bilinear pairing: an Fp12 extension-field tower, a Miller loop and a final exponentiation — several thousand lines of careful big-number code. It is on the family roadmap; until then this page documents the algorithm, and the sibling pages compute the rest of the suite in-browser.

Can SM9 replace SM2, SM3 and SM4? No — they solve different problems. SM9 replaces the certificate infrastructure, not the primitives: internally it relies on SM3 for hashing and key derivation, and the wrapped bulk key typically drives SM4. SM2 remains the answer when certificate-style accountability without key escrow is required.

What exactly is hid? A one-byte function identifier (chosen and published by the KGC) that is mixed into every H1 hash. Because signing keys, encryption keys and key-exchange keys hash the identity together with different hid values, one leaked user key compromises only that one function.

How are identities revoked? There is no CRL mechanism inside SM9. Standard practice: embed expiry in the identity itself (bob@example.com|2026-Q4) so keys must be re-issued periodically, and let the KGC simply stop issuing for revoked identities.

Where is SM9 actually used? In regulated Chinese sectors — banking, government and industry messaging — typically inside closed ecosystems where one authority is acceptable and "encrypt to an email address today, enrol the user tomorrow" is worth the pairing cost.

Self-test
This is a read-only page, so the self-test verifies the page itself: every curve constant shown above is re-checked against independently verified values (the prime p and order N recomputed from the BN parametrisation, both generators checked on-curve with order N), the standard numbers, the template invariants (no DOCTYPE, build marker), cross-links and FAQ presence.