Kit Crypt Bundle Laravel Package

Technical Evaluation

Architecture fit — misaligned with the target stack. The package is a Symfony bundle, not a Laravel package. Its integration surface is the Symfony kernel: a Bundle subclass, a DI Extension with a Configuration tree, compiler passes, and YAML/XML service definitions. Laravel's equivalent is a ServiceProvider registered in bootstrap/providers.php. Nothing in the package participates in Laravel's container, config repository, facades, or deferred-provider model. The bundle's real value — "define keys and ciphers once, let the container wire everything up" — is a Symfony-specific convenience that Laravel cannot consume. What remains is a thin wrapper over cipher primitives that Laravel already ships.

Integration feasibility — technically possible, strategically weak. The package is replaceable, not enabling. Every capability maps to something already in the stack or one maintained dependency away:

The only honest justification for evaluation is legacy interop, and even then the bundle layer adds no value in a Laravel app — you would instantiate the underlying cipher classes directly, which means forking the integration layer to strip the Symfony wiring.

Technical risk — high, concentrated in the worst possible domain. Crypto is the one dependency category where low adoption is disqualifying rather than merely inconvenient.

• Algorithm inventory is largely deprecated. DES (56-bit), 3DES (Sweet32 / 64-bit block), RC2/RC4 (broken), IDEA (legacy), DSA (signature-only — mislabeled here as encryption, which signals imprecise crypto design). Their presence in the feature list suggests the package targets pre-2010 interop.
• No evidence of authenticated encryption. AES-GCM/CCM/ChaCha20-Poly1305 are not called out as first-class modes. Unauthenticated CBC/ECB invites padding-oracle and bit-flipping attacks unless the caller applies an HMAC envelope — pushing cryptographic correctness onto application developers.
• Key management absent. No KMS/HSM integration, no envelope encryption, no key-version identifier in the ciphertext. Rotation requires a hand-designed full re-encryption migration.
• Adoption signal is near-zero. 5 stars, 0 dependents, single-vendor org, MIT with no visible SECURITY.md or CVE process. A vulnerability would have no coordinated disclosure path and no downstream community to have already found it.
• Runtime drift. OpenSSL 3.x moved DES/RC2/RC4 into the legacy provider, and mcrypt was removed in PHP 7.2 — legacy cipher availability varies by host and openssl.cnf.

Key questions to put back to the requesting team:

1. Is the requirement protecting new data or decrypting pre-existing DES/3DES/RC2 artifacts? These have entirely different answers; ~90% of such requests are the former.
2. Does the ciphertext envelope carry an IV, key ID, and authentication tag? Is there a documented versioning scheme?
3. Are the implementations wrappers over openssl_*/phpseclib, or hand-rolled primitives?
4. What are the declared php and symfony/* Composer constraints, and does composer require resolve cleanly on PHP 8.2/8.3?
5. Where does key material live — a key-provider interface, or hard-coded config values?
6. Is there a SECURITY.md, a release cadence, or a responsive maintainer? What is mean-time-to-patch?

Verdict: do not adopt as a platform dependency. The one legitimate use case — decrypting legacy DES/3DES/RC2 data during a migration — is better served by an internally owned, security-reviewed adapter of roughly 150 lines over openssl_*, scoped for deletion once re-encryption completes.

Integration Approach

Stack fit — does not fit and should not be forced. Target is Laravel 10/11/12 on PHP 8.2+. Registering a Symfony Bundle inside Laravel requires a bridge or a hand-written shim that fakes the container contract — a permanent maintenance liability created solely to consume a package with zero dependents. If the underlying cipher classes are genuinely needed, lift them into an internal adapter and drop the bundle entirely.

Migration path — the flow runs the other way. This is not a package you migrate to; it is at best a bridge for data migrated off.

1. Requirement triage. Separate "protect new data" from "read legacy data." Log the outcome as an ADR.
2. Discovery. Inventory the source of the algorithm list — vendor spec, existing encrypted dataset, partner API contract, or developer preference. This determines whether scope exists at all.
3. Default to native. Crypt::encryptString() (AES-256-GCM on Laravel 10.x+) behind a domain-level EncryptionService interface; asymmetric via phpseclib3 RSA-OAEP.
4. Isolate legacy interop. If legacy ciphertext genuinely exists, implement a LegacyCipherAdapter over openssl_decrypt() with explicit padding, hard-fail (never pass through) on failure, and @deprecated marked at creation.
5. Re-encrypt and retire. Backfill job converts legacy ciphertext to a versioned modern envelope; delete the adapter when the last row is converted.

Compatibility — expect friction. Symfony bundle conventions (Extension::load(), Configuration tree, compiler passes, services.yaml resource loading) have no analog in Laravel's config repository or container. PSR-4 autoload may work; service wiring will not. PHP version constraints from a Symfony-2/3-era package are the likeliest hard blocker at composer require.

Sequencing — security review gates everything. A crypto dependency wired in before sign-off becomes load-bearing and unremovable. Order: requirement triage → algorithm inventory → security architecture decision (ciphers, envelope format, key custody) → native implementation or isolated adapter → re-encryption plan → dependency decision recorded as an ADR. Any adoption must carry a named owner and a funded fork.

Operational Impact

Maintenance — high cost, low return. Zero dependents means the team becomes the de facto maintainer: no upstream bug reports, no community patches, no tested upgrade path across PHP or OpenSSL majors. OpenSSL 3.x legacy-provider differences will surface as behavior diverging between local Docker, CI, and production — expect to pin and verify per environment.

Support — no safety net. No visible disclosure policy or CVE process. For crypto this is a hard blocker: a vulnerability arrives as an unreported bug rather than a coordinated advisory. Realistic adoption means an internal fork, line-by-line security review of each cipher path, and ownership of patch latency — costs that dwarf the ~200 lines of code being replaced.

Scaling — CPU-bound, with no key infrastructure. RSA/DSA in PHP are orders of magnitude slower than symmetric ciphers; request-path asymmetric decryption will show in p95 latency. More importantly, there is no KMS/HSM path, no envelope encryption, and no key-version field in the ciphertext — rotation requires a bespoke dual-key read window and a full-table re-encryption. That is an operational scaling problem, not a throughput one, and it is the one that bites in year two.

Failure modes to design against:

Ramp-up — low, because the recommended path is not the package. A Laravel engineer is productive with Crypt::encryptString() and phpseclib on day one; no new mental model required. The package itself adds a small API surface but requires the team to learn Symfony DI conventions and absorb an unaudited crypto implementation — negative knowledge transfer. Budget instead for: a security architecture review (1–2 days), the internal adapter plus known-vector tests (3–5 days), and the re-encryption backfill and cutover (variable, driven by data volume). Net TPM position: decline as a dependency, fund the adapter if legacy ciphertext is proven to exist, and attach a retirement date to it before the first commit.