Miping × Post-Quantum: A Dual-Stack Assessment Framework for Chinese Compliance Systems

The question that isn't on the report yet — but will be

A system that passes its miping self-check has answered "is Chinese cryptography used, and used correctly". One question, however, is bound to enter the evaluation scope: how long is the lifetime of the data these SM2 keys protect?

The logic is short: SM2 rests on elliptic curves → elliptic-curve discrete log is exactly as quantum-fragile as factoring → compliance and quantum safety are orthogonal dimensions. A high miping score does not stop harvest now, decrypt later (see whose data moves first) — recorded TLCP traffic can be retroactively decrypted the day quantum hardware matures, same as anything else.

Where the domestic process stands: NIST's ML-KEM/ML-DSA are standardized internationally (FIPS 203/204); China's commercial-cryptography post-quantum standards research is underway, proceeding in parallel with the international algorithm families. For critical-infrastructure operators, "wait for the domestic standard" is a defensible position — but data lifetime doesn't wait, which is precisely why a dual-stack framework matters.

Dual-stack isn't two systems — it's one matrix

Split "compliance obligation" and "quantum foresight" into two independent axes:

The defining property of dual-stack is parallel, not replacement: an ingress can listen for TLCP (domestic compliance) and hybrid TLS (foresight) at the same time; the SM family continues to serve existing obligations while PQC layers on only where long-lived secrets are wrapped. No rule anywhere requires choosing one.

The self-check: five items on top of the standard checklist

Building on the miping self-check framework, append a "quantum exposure assessment" section:

• List every SM2 public-key usage (certificates, signatures, key exchange), labeling each with its data/signature lifetime
• Identify secrets with >10-year lifetimes (government archives, medical records, judicial evidence) — first priority for HNDL
• Transport assessment: can the ingress offer hybrid TLS in parallel (OpenSSL 3.5+ X25519MLKEM768 group, see ML-KEM, explained)? Especially meaningful for international visitors and long-lived sessions
• Stock data: SM4-encrypted with keys that never traveled through public-key wrapping → quantum risk contained; keys transported inside SM2 envelopes → those envelopes are the future decryption doorway
• Write one line of "post-quantum readiness" into the cryptography master plan — the next assessment cycle will very likely ask

Why now: the cost curve is asymmetric

• Now: one extra section in the existing miping documentation + a parallel listener at the ingress — near-zero marginal cost
• Later: if you wait for standards to settle, long-lived data wrapped in SM2 envelopes will have accumulated un-revocable HNDL exposure — that exposure cannot be retroactively removed

This is the shared tense of all PQC migration: you protect every byte from today forward; you cannot protect yesterday's leaks.

Implementer's note

Building the site's SM2 tool family made the ecosystem gap vivid: browser-side dependencies for Chinese crypto (the sm-crypto family) are far less mature than WebCrypto's built-in classical algorithms — and PQC's browser story (liboqs wasm) is more primitive still. Each stack in the dual-stack is waiting for its own dependency chain. That gives the Chinese-crypto tools an unexpected role: they are already the full rehearsal for "how non-native algorithms enter the browser" — when ML-KEM's wasm toolchain matures, every lesson the SM family learned (payload control, key formats, random-source quality labeling) transfers directly.

Related reading

• Miping self-check checklist: GB/T 39786, layer by layer
• Post-quantum migration self-check: 12 items
• Chinese-crypto HTTPS deployment: TLCP dual certificates
• SM2 vs. RSA, how to choose