Crypto Sm Laravel Package

Product Decisions This Supports

• Compliance and market roadmap: If the product targets China-market or regulated use cases requiring SM2/SM3/SM4 and GM/T-aligned cryptography, v0.3.0 strengthens the case for a time-boxed pilot. New SM2 ASN.1 ciphertext, compressed public-key import, SM4-CCM, and key-exchange official vectors reduce custom interoperability work with partner systems, CAs, and gateways.
• Build vs. buy: The release shows active maintenance, official-vector testing, 93.94% coverage, and a critical security fix. For a Laravel/PHP product, buying/adopting this package is lower risk than implementing Chinese cryptographic primitives in-house—provided adoption includes version pinning, security review, and regression tests.
• Feature and integration planning: v0.3.0 unlocks roadmap items that depend on standard ciphertext formats, compressed keys, AEAD via SM4-CCM, and validated key exchange. Product should prioritize these only where customer or regulatory requirements actually demand GM/T interoperability.
• Security and upgrade planning: The critical GCM GHASH domain-separation fix is a must-upgrade item if GCM is used. The runtime deprecation notices for future-major removals mean product/engineering should budget migration work now rather than treat v0.3.0 as a long-term stable baseline.
• Release readiness: The package is still pre-1.0. Treat v0.3.0 as a controlled pilot candidate, not an unqualified production default, unless the team can absorb breaking changes and monitor security advisories.

When to Consider This Package

• Consider it when: the product must implement or interoperate with SM2/SM3/SM4, GM/T standards, or RFC 8998 behavior in a Laravel/PHP service; the team needs official-vector-backed cryptography rather than DIY primitives; and there is appetite for a pre-1.0 dependency with active security maintenance.
• Consider it for: signing/verification, encryption, key exchange, SM4-CCM AEAD, ASN.1 ciphertext interoperability, and compressed public-key import in China-facing integrations.
• Look elsewhere when: the product only needs general-purpose cryptography and can use mature platform libraries; the organization requires a stable 1.0/LTS dependency with no planned breaking changes; there is no capacity for crypto/security review; or certification requirements demand FIPS/Common Criteria/HSM-backed modules rather than a PHP package.
• Do not adopt blindly when: the team cannot pin versions, run official-vector regression tests, monitor deprecations, or isolate the package behind a service boundary. Key management, randomness, protocol design, and side-channel considerations remain product/security responsibilities.

How to Pitch It (Stakeholders)

• To executives: This package can accelerate China-market and regulated cryptography features without building SM algorithms from scratch. v0.3.0 adds meaningful interoperability features and fixes a critical security issue, which signals active maintenance. The trade-off is pre-1.0 maturity, so recommend a scoped pilot with security review and a migration budget rather than broad production rollout.
• To engineering: Adopt v0.3.0 with a pinned version, upgrade immediately if GCM is used, add GM/T and RFC 8998 vector tests to CI, and track the new deprecation notices as future-major migration work. Keep the package behind a crypto service boundary and avoid letting application code depend directly on its internals.
• To security/compliance: Validate the claimed GM/T conformance and RFC 8998 fixes independently, review key-management and randomness assumptions, and confirm that the package’s scope matches the compliance requirement. The release’s official-vector testing is a positive signal, but it does not replace architecture and operational security review.