Crypto Laravel Package

Technical Evaluation

Architecture fit

The package is a conventional Laravel wrapper: service provider, facade, publishable config, PSR-friendly core. It drops into the container cleanly and reads naturally to any Laravel developer. The problem is that it is architecturally redundant with the platform. Laravel already ships Illuminate\Encryption\Encrypter (AES-256-CBC + HMAC, AES-256-GCM), the Crypt facade, Hash (bcrypt/Argon2), signed URLs, and encrypted cookies; PHP ≥7.2 ships libsodium. A third-party crypto layer only earns a place in the architecture if it exposes something the framework does not — envelope encryption, key IDs with rotation, asymmetric primitives, or a KMS abstraction. This one is a thin ergonomic wrapper, not a component. The correct framing for the TPM is pattern source, not dependency.

Integration feasibility

Mechanically trivial: composer require, auto-discovery on Laravel 5.5+, manual registration on Lumen. The blocker is lifecycle, not effort. The repository is archived, with 10 stars, zero dependents, and no CVE channel. Installation is a one-way door into permanent self-maintenance. Composer resolution against Laravel 9+/PHP 8.x is unverified and likely to fail on illuminate/* constraints — treat that as a probable hard stop until a spike proves otherwise.

Technical risk — HIGH

Cryptography is the one dependency class where "it works" and "it is correct" are different questions, and the failure mode is silent. Zero adversarial review and zero production hardening is disqualifying for anything customer-facing or regulated. The specific items that must be verified before any use, each disqualifying if wrong: source of randomness (random_bytes/sodium vs. anything else), AEAD vs. CBC-with-HMAC construction, nonce/IV generation and uniqueness, key derivation approach, and any residual mcrypt fallback (removed in PHP 7.2).

Key questions

1. Which primitives does it wrap, and does it add anything over Encrypter + sodium?
2. Is the construction AEAD or CBC-with-HMAC — is there padding-oracle exposure on attacker-supplied ciphertext?
3. How are keys derived, stored, and rotated — is there a key-ID scheme, or is rotation a re-encrypt-everything event?
4. What are the composer.json PHP and illuminate/* constraints?
5. Do we hold any production ciphertext encrypted with this package that must remain decryptable?
6. Does the 7.46 opportunity score reflect a real capability gap, or a tidy small MIT repo? (Expect the latter; the 0.3 health score is the honest read.)

Integration Approach

Stack fit

Idiomatic to the framework, hostile to the security posture. Use it as discovery material for a one-day spike, not as a runtime dependency. If a specific primitive it exposes is genuinely needed, reimplement that primitive on sodium_compat or openssl_* behind an interface we own.

Migration path

• New work: do not adopt. Standardize on Encrypter for at-rest field encryption and libsodium for everything the framework does not cover. This should be the default and require no further analysis.
• Existing usage found in the estate: dual-read path — decrypt with the legacy package, re-encrypt with the target — then a backfill sweep, verified to zero, before removing the dependency.
• If adoption is mandated: fork to a private, pinned repo under our org with a named owner and a security review cadence. That is a first-party code commitment from day one, not a dependency decision.

Compatibility

Validate PHP and Illuminate constraints first — this is a potential hard stop, not a nice-to-have. Then verify ciphertext portability across OpenSSL versions; if cipher and mode are not pinned explicitly, legacy ciphertext may not survive an OS upgrade.

Sequencing

1. Threat-model the data class that needs protection.
2. Confirm the capability gap against core Laravel + sodium (expect none).
3. If a gap exists, extract the algorithm and reimplement — do not depend on the package.
4. Put it behind an internal SecretBox/EncryptionService interface so the implementation is swappable.
5. Design the key-rotation path up front, not retrofitted.
6. Only then integrate.

Wrap it, don't sprinkle it: a single application-owned boundary class binding the package (or our replacement) means swapping one file instead of grepping dozens of call sites when it dies.

Operational Impact

Maintenance

Archiving transfers all maintenance to us: security patching, PHP/Laravel compatibility, and ciphertext compatibility. The hours are small; the risk is unbounded, because nobody is watching upstream. A crypto dependency without a named owner is an unowned liability — budget a standing owner or do not take it.

Support

No upstream support, negligible community. The internal escalation path is "whoever forked it." That must be an explicit, accepted trade-off rather than an accident discovered during an incident.

Scaling

Throughput is a non-issue — the primitives are native and the wrapper overhead is negligible. The real scaling problem is key management and rotation. Every ciphertext written today is a permanent obligation to hold that key. Without a key-ID scheme, operational cost compounds with data volume and retention. Model this before writing the first record.

Failure modes

• Silent decryption failure after a PHP/OpenSSL upgrade, discovered only when a user reads their own data.
• IV/nonce reuse under the wrong construction — invisible in tests, catastrophic in effect.
• Padding-oracle exposure if CBC is used without a MAC.
• Key material leaking into a published config file or committed .env.
• Hard break on a future PHP release with no upstream to patch.
• Bus factor of one on a fork with no test suite.

Ramp-up

The API is small; a developer is productive in a day. Assurance onboarding is the expensive part — nobody on the team can credibly sign off on a construction they did not write, and an archived repo offers no external signal to lean on. Keep the effort at the evaluation layer: spend a day on a spike, capture the primitives it uses, close it out. The low score is the correct read; the high opportunity score reflects a tidy small repo, not a capability we should adopt.