GmSSL: China's national cryptography algorithms as a C library

One library for a national algorithm family

GmSSL is an open source commercial cryptography library independently developed by Peking University, and its scope is the full Chinese national suite, what the documentation calls guomi or national cryptography: the SM2 and SM9 public key algorithms, the SM3 hash, the SM4 block cipher and the ZUC stream ciphers, plus the secure protocols built on them. Coverage extends to mainstream operating systems and processors including mobile platforms, to national cryptographic hardware such as crypto keys and crypto cards, and to a feature-rich command line tool alongside programming interfaces for compiled languages. The license is Apache-2.0, the implementation language is C, and the project is old enough and significant enough that its version 3 redesign is the current story, with CI workflows running Linux, Windows, Android, iOS and OpenHarmony builds on every change.

Designed for MCUs, certification and side channels

Version 3's four stated design goals read like a requirements document from the embedded and regulated world. Ultra-lightweight: memory requirements and binary size are drastically reduced, and the library does not depend on dynamic memory allocation, so it can run in low-power embedded environments without an operating system, on MCUs and SOCs. More compliant: the build can be configured to include only the national algorithms and the TLCP protocol, which makes it easier for dependent applications to pass cryptographic product model certification, avoiding the security and compliance problems of mixed-in non-national or broken algorithms. More secure: TLS 1.3 support arrives with the RFC 8998 national cipher suites, key encryption protection is on by default, and side-channel resistance is improved. And more portable: the CMake build system dropped the Perl dependency that OpenSSL-style builds carried, cooperating directly with Visual Studio and the Android NDK.

cmake, make, make test, sudo make install

The documented build is the standard CMake sequence, no configuration scripts in sight:

mkdir build
cd build
cmake ..
make
make test
sudo make install

After installation, the gmssl command line tool lands in the default binary directory, a gmssl header directory is created for includes, and the dynamic libraries libgmssl.so or libgmssl.dylib are installed, with a static libgmssl.a available by configuring with -DBUILD_SHARED_LIBS=OFF. Windows developers get their own three-line recipe under the Visual Studio command prompt:

mkdir build
cd build
cmake .. -G "NMake Makefiles" -DWIN32=ON
nmake

The pairing of make test in the default flow and a dedicated ENABLE_TEST_SPEED switch for benchmarks signals the project's priorities: correctness first, performance opt-in.

The algorithm inventory, minus RC4 and MD5

The block cipher coverage is deep where it matters: SM4 in CBC, CTR, GCM, ECB, CFB, OFB, CCM and XTS modes, with AES alongside in CBC, CTR and GCM. Stream ciphers are ZUC and ZUC-256, the national standard family. Hashing spans SM3 and the SHA family through SHA-512. Public key work covers SM2 and SM9 for both encryption and signatures, and the post-quantum shelf holds LMS and HSS hash-based signatures, with the changelog adding CRYSTALS-Kyber key encapsulation plus SM3-based SPHINCS+ and XMSS since 3.1.1. MACs include HMAC, GHASH and CBC-MAC, key derivation covers PBKDF2 and HKDF, and randomness comes from Intel RDRAND or the NIST SP 800-90A HASH_DRBG. The changelog also records a deletion, the broken RC4 and MD5 algorithms were removed entirely, which is the kind of subtraction a cryptography library should be proud of.

TLCP, TLS 1.2 and TLS 1.3 with Chinese suites

Protocol support is layered by generation, each with its exact suite and standard cited. TLCP 1.1, the national transport protocol, implements TLS_ECC_SM4_CBC_SM3 with the identifier 0xE0,0x13 per GB/T 38636-2020 and GM/T 0024-2014. TLS 1.2 carries TLS_ECDHE_SM4_CBC_SM3, 0xE0,0x11, under the same standards. TLS 1.3 implements TLS_SM4_GCM_SM3, 0x00,0xC6, per RFC 8998, the specification that brought SM suites into the modern protocol. The changelog since 3.1.1 shows the TLS 1.3 stack maturing in specific increments, PSK-DHE and PSK-only handshakes with 0-RTT, HelloRetryRequest negotiation, the SNI extension, Certificate Transparency and OCSP stapling extensions, a conventional P-256 with AES128 and SHA256 suite for interop, and a rewrite of the protocol stack as a state machine supporting non-blocking operation, the property event-driven applications need.

Six bindings, and an honest break with OpenSSL

Language reach is handled through sibling repositories rather than one omnibus package: GmSSL-Java via JNI, GmSSL-PHP as a PHP extension, GmSSL-Go through CGO, GmSSL-Python through ctypes, gmssl-rs as a Rust wrapper and GmSSL-Nodejs for JavaScript. The compatibility story is stated without softening: version 3.0 rewrote all the code and changed the API, so GmSSL is not compatible with OpenSSL and cannot directly replace it at compile time. The mitigation is another subproject, OpenSSL-Compatibility-Layer, which lets applications like Nginx call GmSSL functionality through an OpenSSL-shaped interface, with versions 1.16 through 1.25 of Nginx tested against it. For teams migrating existing OpenSSL software, that layer and its tested version window are the first things to check.

SDF and SKF hardware, SoftSDF, and disclosed-method benchmarks

Hardware integration covers the two national form factors: SDF devices, typically PCI-E crypto cards or server crypto machines, and SKF devices, the small USB crypto keys, both supported natively. The list of tested product models is candid to the point of being empty, reading only "to be added", and the practical answer is the SoftSDF subproject, a software SDF implementation that is functionally equivalent but without the key protection of real hardware, intended for development and testing before swapping in hardware at deployment. Benchmarks are published with their methodology exposed, single core, single thread, best of five runs, turbo and core-parking untouched, hence slightly flattering, and the numbers include an Apple M2 reaching 15,340 MiB per second on the accelerated SM4 CTR-32 path against roughly 160 to 190 MiB per second for plain SM4 on a 2018 Intel i7, with SM2 signing at over 110,000 signatures per second on the amd64 assembly path. Version 3.2.0 was released 2026-06-21, with the last push on 2026-06-30.

Editorial conclusion

Use GmSSL when your system must implement China's commercial cryptography standards, whether for regulatory compliance, interoperation with domestic infrastructure, or hardware integration over SDF and SKF devices. Use OpenSSL when you need its ecosystem and API compatibility, remembering that GmSSL 3 cannot drop in for it without the separate compatibility layer. Verify first that your required cipher suite, TLCP, TLS 1.2 with SM suites or TLS 1.3 per RFC 8998, is the one your counterparty mandates, and benchmark on your own hardware using the documented ENABLE_TEST_SPEED procedure rather than the README's machines.

Frequently asked questions

Official sources

1. guanzhi/GmSSL on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases