- Role
- Personal project
- Status
- Released
- Release
- v1.11.0
- Key outcome
- In-CI leak-regression gates for secret-touching paths.
- Stack
- RustCryptographyno_std
cargo add gmcrypto-core
What it is
gm-crypto-rs implements GB/T 32905 (A Chinese national cryptographic hash standard (GB/T 32905) producing a 256-bit digest — broadly the SM-family counterpart to SHA-256. hash),
GB/T 32918 (A Chinese national public-key standard (GB/T 32918) built on elliptic curves — used for digital signatures, key exchange, and public-key encryption. public-key sign / verify / encrypt / decrypt
and, since v1.1, key exchange with key confirmation),
and GB/T 32907 (A Chinese national block cipher standard (GB/T 32907) with a 128-bit block and 128-bit key, used for bulk symmetric encryption. block cipher) in pure Rust. The crate
graph is A Rust build that doesn't link the standard library, so the code can run in constrained environments — embedded targets, kernels, WebAssembly. It has only `core`; heap allocation is opt-in, requiring `alloc` and an explicit allocator. + alloc, builds on
wasm32-unknown-unknown, and ships RustCrypto-trait
fits for digest, mac, and cipher
— plus, since v1.11, opt-in aead 0.6 for SM4-GCM /
SM4-CCM. Since v1.3 it also parses X.509 v3 certificates and verifies their
SM2-with-SM3 signatures (the GM/T 0015 profile — strict-DER, no
trust decisions), with the matching C-ABI entry points (in the
gmcrypto-c crate) following in v1.4. v1.6 through v1.9
build out a TLCP (GB/T 38636) toolkit: the key schedule and a
no-confirmation SM2 key-exchange path (v1.6), record protect /
deprotect (v1.7), certificate-pair and chain signature verification
(v1.8), and — since v1.9 — the whole toolkit reachable from C.
The published
gm-crypto-rs-demo
is a consumer and smoke-test tour of representative crate
capabilities, including hashing, signing and verification,
encryption and decryption, key exchange, and encoding flows. Its
dependency is pinned to gmcrypto-core = "=1.11.0" so
the demo and this evidence snapshot refer to the same release.
The problem
Rust already has SM2 / SM3 / SM4 implementations, and the good
ones are designed for Code whose running time does not depend on secret values, so an attacker can't recover secrets by measuring how long it takes. It's a design target, not a guarantee — some hardware can still leak. secret-dependent
operations. But design intent is asserted once, at review time,
and then erodes quietly — a refactor, a new fast path, a
dependency bump, and a timing leak slips back in with nothing to
catch it. This SDK targets a combination that makes that erosion
easy: byte-level GB/T conformance, a no_std / wasm
core, secret-touching paths that must stay constant-time-designed
across releases, and a C ABI that hands those same paths to
non-Rust callers (C, C++, Go, Zig, Python). The question it is
built around isn't is it constant-time today — it's
what keeps it constant-time on every commit.
Constraints & key decisions
Verify continuously, don't assert once.
Constant-time behavior is treated as a property CI re-checks, not
a claim review signs off. A dudect-bencher harness
exercises twenty secret-touching paths on every run; a core set
is gated at |τ| < 0.20, so a
timing regression fails the build instead of waiting for someone
to notice. The harness reports detection events — a low
|τ| means no leak was detected under the budget
given, not that none exists (the wording is
dudect-bencher's own).
Cost: every PR pays the measurement budget, and
statistics can never turn "not detected" into "absent."
Gate the core, observe the rest. Not every path
fits a PR's time budget, so the harness splits them. Gated
(build-failing), sixteen paths: both scalar multiplications
(fixed- and variable-base), SM2 sign, decrypt, and key exchange,
SM4 key schedule, SM4 encrypt (default linear-scan and bitsliced
SIMD S-box), SM4-CTR, CBC-decrypt fanout, single-shot SM4-GCM /
SM4-CCM decrypt plus buffered SM4-GCM decrypt, SM4-XTS decrypt,
encrypted-PKCS#8 decrypt, and — since v1.7 — the TLCP CBC record
deprotect, the Lucky13 residual guard. Telemetry-only, four: the
field-inversion diagnostics, the k-class sign, and — since
2026-06-17 — HMAC-SM3, watched on the nightly run against a
0.55 gross-regression sentinel rather than the
0.20 gate — shared-runner class-split noise made
their tighter gates fire falsely, so each was demoted with the
reasoning published. Cost: the telemetry paths are
watched, not enforced, and the two-tier split is a permanent
surface to maintain.
A safe core; SIMD is opt-in.
gmcrypto-core forbids unsafe code in its
[lints] table (unsafe_code = "forbid").
The bitsliced SIMD S-box needs unsafe, so all of it
is quarantined in a separate gmcrypto-simd crate
behind the sm4-bitsliced-simd feature.
Cost: the fast path isn't the default — you opt
into SIMD, and the stock build runs the slower linear-scan S-box.
Constant-time-designed arithmetic, caveat stated.
Secret-dependent arithmetic is built on subtle and
crypto-bigint, and secret material is zeroized on
drop via zeroize. The design targets constant time
but can't guarantee it everywhere. Cost: on CPUs
whose multiply latency is data-dependent (some older x86, some
embedded), the timing properties don't hold — stated plainly under
What it isn't rather than buried.
Ship the core first, the FFI next — and skip releases that
change nothing. Cipher modes land on a
core-in-vN / FFI-in-vN+1 cadence: the SM4-XTS core
shipped in v0.12 and its C ABI in v0.13; the in-place multi-sector
disk helper in v0.15 and its FFI in v0.16; SM2 key exchange in
v1.1 and its C ABI in v1.2; X.509-with-SM2 in v1.3 and its C ABI
in v1.4. When a cycle changes no
output bytes — v0.14 was a cargo-fuzz parser-fuzzing
sweep that found zero crashes — it merges as assurance and is never
published, so crates.io skips 0.14.0. The same rule then
scaled up across the 0.17–0.23 gap — chiefly the
v0.21–v0.23 readiness work (public-API freeze,
crypto-bigint decoupling, a multi-model adversarial pre-1.0
re-audit) — which stayed unpublished and shipped together in the
deliberate 1.0.0 release.
Cost: the version line carries a deliberate gap to
explain, and the C ABI doubles the surface every mode has to be
tested and owned across three published crates.
Evidence
Every output is checked for byte-identity: against the standard
KAT vectors, against GmSSL 3.2.0 for interop — an in-CI job
pinned to a from-source oracle build since v1.10 — and against
OpenSSL 3.x SM4-XTS (xts_standard=GB)
for the tweakable mode. The leak-regression gates above run in CI
on every commit, and the core forbids unsafe code via its
[lints] table. The v0.14 cycle added a
cargo-fuzz (libFuzzer) harness over the
untrusted-input decode / decrypt surface — sixteen targets then,
thirty as of v1.8, thirty-three as of v1.11 — run as a nightly sweep. All of it is inspectable: the source, the CI workflow, and
the A statistical test for timing leaks: it times an operation over two input classes and checks whether their timing distributions differ. It detects leaks under a measurement budget — it can't prove none exist. harness are public, alongside the published
gmcrypto-core crate, its docs.rs
reference, and the runnable demo.
Three of those properties, pinned to v1.11.0, each a link
to the exact line:
- Secret-derived equality uses the crate's constant-time comparison path; the linked source shows that implementation choice, while the dudect evidence below remains empirical rather than a proof — cipher.rs:627 .
- The core crate forbids unsafe code — Cargo.toml:177 .
- A dudect timing-leak gate runs on every PR — dudect-pr.yml:169 .
Two more, specific to the constant-time claim — the parts that are easy to assert and hard to prove:
- The gate has teeth — a deliberately-leaky
negative_controlthe harness must flag, or CI fails — timing_leaks.rs:167 . - Stated honestly — the harness detects leaks; it does not prove constant-time — README.md:76 .
Four notes unpack the evidence boundary: how the CI gate works, and why the negative control — not the green checks — is the part worth showing; byte identity as an interop test; and unsafe as an explicit opt-in.
Published measurements and current policy share one view: observed values are evidence from a named run, while the gate and sentinel are enforcement thresholds rather than proof.
dudect reports detection events — a low |τ| means no leak was detected under the budget given, not that none exists.
| Target | What it measures | |τ| | Gate | Status |
|---|---|---|---|---|
ct_sign |
SM2 sign, split by private key d | 0.0044 | < 0.20 | under gate |
ct_sign_k_class |
SM2 sign, split by nonce k magnitude | 0.0708 | < 0.55 (nightly sentinel) | under sentinel |
ct_fn_invert |
Direct Fn::invert diagnostic | 0.0071 | < 0.55 (nightly sentinel) | under sentinel |
ct_fp_invert |
Direct Fp::invert diagnostic | 0.0063 | < 0.55 (nightly sentinel) | under sentinel |
negative_control |
negative_control — must fire here (proof the detector isn't blind) | > 1.0 | > 1.0 | must fire |
crypto-bigint 0.6 ConstMontyForm::invert |
before (crypto-bigint 0.6) | ≈0.7 | < 0.20 | Over gate — caught |
crypto-bigint 0.6 ConstMontyForm::invert |
after (0.7.3 upgrade) | ≈0.006 | < 0.20 | under gate |
Measured: v0.2 W0 harness, 100K samples (pre-2026-05-12 runner). The k-class sign and the two invert diagnostics later moved to telemetry + a |τ| ≥ 0.55 sentinel. Source: gm-crypto-rs SECURITY.md @ v1.2.0 ↗
The release line carries deliberate gaps: a cycle that changes no output bytes merges without a published version. Why, in one note.
- Current
- v1.11.0, 2026-08-01 — opt-in RustCrypto
aead0.6 trait fit for SM4-GCM / SM4-CCM. The C ABI surface stays 104 entry points. - Unpublished
- Four gaps in the published version line — v0.14, 0.17–0.23, v1.5, v1.10 — none of them changed an output byte.
- Full history
- Every cycle from v0.6.0 →
Next
- Next
- The TLCP (GB/T 38636) arc begun in v1.6 closed with v1.9; v1.11 then closed the long-parked RustCrypto
aead0.6 trait fit. No successor arc is committed to a version yet. Still parked: AVX-512sbox_x64, and streaming / incremental CCM. Permanently out of scope, not deferred: endpoint identity binding — the TLCP equivalent of hostname verification — stays the caller's.
What it isn't
- Not a TLS/TLCP stack — the
tlcpwork is a toolkit of primitives (key schedule, record protect / deprotect, chain and pair verification). There is no handshake state machine, no negotiation, and no session management: a caller drives the protocol, as the v1.9 C examples do. - Not endpoint authentication —
verify_chain/verify_pairestablish structural trust only. Binding a verified chain to a peer identity, the TLCP equivalent of hostname verification, stays the caller's permanently. - Not SM9, ZUC, or post-quantum.
- Not an HSM / SDF / SKF integration.
- Not a certified cryptographic module under the U.S. Federal Information Processing Standards (FIPS) or another certification program.
- Not constant-time on CPUs with data-dependent multiply latencies (some older x86, some embedded).
Personal project. Cross-checked for byte-identity against GmSSL and OpenSSL, but not affiliated with, endorsed by, or certified by either project — or by any standards body or vendor.