Crypt Bundle Laravel Package

Product Decisions This Supports

• Encryption-at-rest roadmap. This release is a platform-compatibility maintenance release (PHP 8+ via an updated defuse/php-encryption), not a feature release. It sets the minimum runtime for the package and lets you plan an encryption-at-rest capability on a supported PHP baseline.
• Build vs. buy. Reinforces "buy": you are not shipping your own cipher code. The underlying primitive (authenticated symmetric encryption) is delegated to a maintained library, so your build cost is limited to integration, key lifecycle, and schema work.
• Compliance-driven scope. Supports decisions on storing PII, credentials, tokens, or customer secrets in the database and whether encrypted casts / encrypted columns are a viable substitute for a managed KMS.
• Upgrade sequencing. A major version bump gated on a modern PHP runtime is a forcing function for the PHP 8 migration and for a data-migration plan (existing ciphertext must still decrypt).
• Not supported by this release: envelope encryption, key rotation UX, searchable encryption, asymmetric key exchange, HSM integration. Do not cite this release as evidence for those roadmap items.

When to Consider This Package

Consider it when:

• You are on (or moving to) a PHP 8+ / modern Laravel runtime and have a concrete need to encrypt application-level data — model attributes, columns, cached payloads, or files — beyond relying only on disk-level or transport-level protection.
• You want a small, auditable integration surface over a well-known crypto library rather than bespoke encryption code owned by a small team.
• Your threat model is "database dump, backup leak, or over-broad internal access," not "compromised application server." Application-level encryption gives limited protection once an attacker has your runtime and keys.
• You can accept a dependency bump as the primary change in a release — i.e., your team has capacity to re-run decryption regression tests rather than expecting new capability.

Look elsewhere when:

• Laravel's built-in Encrypter / encrypted casts already cover the requirement. For most attribute- and column-level needs, the first-party solution is fewer moving parts and a smaller supply-chain surface.
• You need managed keys: KMS/HSM, envelope encryption, per-tenant key isolation, envelope-wrapped DEKs, or rotation without re-encrypting all rows.
• You need searchable/orderable ciphertext, deterministic encryption for lookups, or joins on encrypted columns.
• You require FIPS 140 validation, formal third-party crypto audit artifacts, or post-quantum readiness.
• Your runtime cannot move to PHP 8, or you have long-lived ciphertext whose format compatibility with the new dependency version is unverified.
• You need asymmetric/multi-party crypto (signing, key exchange) — a symmetric-only wrapper is the wrong tool.

Before adopting or upgrading: confirm the 2.0.0 bump does not alter ciphertext format or key-derivation behavior, verify at least one round-trip decrypt of data written by the prior version, and check transitive constraint conflicts with your Laravel/PHP matrix.

How to Pitch It (Stakeholders)

To executives: "This release is a maintenance update — it modernizes the package's crypto dependency for PHP 8. No new product features, no new attack surface we haven't already reviewed. The recommendation is to treat it as part of our PHP 8 upgrade work, not as a standalone initiative. Decision requested: whether application-level encryption of sensitive fields is in scope this year; if yes, this package is a low-effort option; if our compliance needs are KMS-grade, we should budget for a managed key service instead."

To engineering: "v2.0.0 raises the floor to PHP 8 and refreshes defuse/php-encryption. Treat it as a compatibility/security-hygiene release: pin the new major, confirm no transitive dependency conflicts, and add a regression check that data encrypted under the previous version still decrypts. Do not assume new APIs. If we adopt the package, we own the key lifecycle and rotation story — the package does not solve that for us. Also note the supply-chain implication: this release is essentially a dependency change, so our review effort should go into vetting that dependency, not the wrapper."