One Sm Laravel Package

Product Decisions This Supports

• China market-entry gating. If your roadmap includes mainland China customers, government integrations, or data flows to PRC partners, SM2/SM3/SM4 support is often a contractual or regulatory checkbox (Cryptography Law, 商用密码 requirements, MLPS 2.0, bank/UnionPay partner specs). This package tells you the "algorithm availability" part of that gate is cheap — days, not quarters — so the real decision is commercial/legal, not technical.
• Build vs. buy vs. wrap. Three options: (a) hand-roll SM primitives, (b) depend on ext-openssl (1.1.1+ ships SM2/SM3/SM4), (c) adopt a library like this. This package makes (c) viable for teams on older PHP builds, shared hosting, or environments where the OpenSSL SM provider isn't compiled in. It reframes the build/buy question from "can we do crypto?" to "how do we isolate crypto behind an interface?"
• Interop is the actual product risk, not the math. Chinese counterparties are inconsistent about SM2 ciphertext layout (C1C3C2 vs. C1C2C3), hex vs. base64, and the 04 uncompressed-point prefix. A pure-PHP implementation with these knobs saves you the discovery cycle that otherwise burns a sprint in partner UAT. Budget the decision as "one integration spike per partner," not "one crypto ticket."
• Feature scoping: signing adapter and field-level encryption. Concrete use cases this unblocks: request signing for PRC partner APIs, SM3 hashing for integrity/dedup keys, SM4 for column-level encryption of PRC PII (ID numbers, phone numbers) in multi-tenant Laravel apps.
• Vendor/architecture decision on key custody. The package does not solve key management, rotation, HSM, or audit. Deciding to adopt it is implicitly deciding where keys live — which is the expensive, high-stakes half of the problem and should be scoped separately.
• Effort estimation. Wrapping this behind a CryptoProvider interface is roughly 1–2 sprints including test vectors and partner interop; replacing it later with OpenSSL or a commercial SDK/HSM is then a swap, not a rewrite. That optionality is the main strategic argument for adoption.

When to Consider This Package

Consider it when:

• You need SM2/SM3/SM4 inside a Laravel/PHP service and ext-openssl on your target runtime lacks SM support.
• Volumes are modest (API signing, credential encryption, field-level PII) rather than bulk encryption of large payloads — pure PHP will be orders of magnitude slower than a native implementation.
• You need fine-grained control over SM2 encoding/interop quirks that a native binding may not expose.
• You can pin the version, vendor it, and wrap it behind your own interface so it is replaceable.
• The data isn't the crown jewels — or it is, and you're prepared to have the code reviewed before it touches production keys.

Look elsewhere when:

• You need throughput, constant-time behavior, or side-channel resistance. Pure-PHP crypto is not constant-time and is a poor fit for high-value long-lived keys.
• You need HSM/KMS integration, key rotation, FIPS-style certification, or an audited supply chain — go to a commercial 商用密码 vendor or a native binding.
• You need SM9, certificate parsing, or full PKI/CA workflows.
• You require vendor SLAs, security advisories, or a maintained release cadence. Signals here are thin: ~190 stars, 0 dependents, no visible audit, and a small-maintainer bus factor. Treat it as "a well-formed implementation you must own," not "a dependency you can lean on."
• Your team has no one who can read the crypto and validate test vectors — in which case adopting any third-party crypto without review is the wrong move.

How to Pitch It (Stakeholders)

To executives: This is a small, free, open-source PHP library that gives us the Chinese national cryptographic algorithms (SM2/SM3/SM4) that PRC partners and regulators increasingly require. It removes the "we can't technically support China" blocker in about one to two sprints of integration work, versus a much larger build or a commercial licensing conversation. It is not a complete compliance solution — key management, audit, and certification remain separate, scoped decisions. Recommended ask: a time-boxed spike plus a security review, not a commitment.

To engineering: Treat it as a reference implementation we wrap, not a black box we depend on. Put it behind our own CryptoProvider interface, pin and vendor the version, add known-answer test vectors, and instrument real partner payloads early — interop encoding is where the time goes, not the algorithm. Assume we may swap to ext-openssl SM support or an HSM-backed service later, and design so that swap is a config change. Do not use it for high-volume or high-value key material without a review of constant-time properties and key storage.