Crypto Laravel Package

Product Decisions This Supports

• Build-vs-buy-vs-standardize for cryptography-adjacent features. This package is an input to that trade study, not an answer. It is relevant when scoping field-level encryption of PII, at-rest encryption of tokens/secrets, signed URLs and tokens, webhook HMAC verification, or secure secret handling — but the realistic outcome of the evaluation is "standardize on Laravel/PHP native primitives," not "adopt this dependency."
• Closing the "buy" branch early. With an archived repo, 10 stars, 0 dependents, and a low health score, there is no maintainer, no CVE response, and no community validation. That removes procurement-style due diligence from the critical path: the decision collapses to build on Laravel natives vs. fork this MIT code and own it outright.
• API/ergonomics reference for internal helpers. Its only durable residual value is as a design pattern — a facade-first crypto surface (encrypt/decrypt/hash/sign). Engineering can borrow the ergonomics without taking on the maintenance liability, which is a cheap way to improve developer experience on an otherwise boilerplate-heavy task.
• Compliance and risk roadmap input. Any feature touching SOC 2 / PCI / GDPR / HIPAA exposure requires key rotation, algorithm agility, audit logging, and a patched dependency. This package does not credibly deliver that today, so it should not appear as a dependency on a compliance-driven roadmap.
• OSS risk register entry. Log it as an end-of-life candidate. If a team proposes using it, the counterproposal is a supported alternative (Laravel Crypt, libsodium, phpseclib, or a managed KMS) or an explicitly resourced internal fork with a named owner and a security review slot.
• Capacity allocation. Cryptography plumbing is table stakes, not a differentiator. The PM decision this informs is "spend a few days on thin internal helpers and move on," not "carve out roadmap space to maintain a 10-star abandoned wrapper."

When to Consider This Package

Consider it only when:

• You need a read-only reference implementation of a Laravel-idiomatic crypto facade and want to compare API shape before building your own.
• You are prototyping something internal and non-sensitive, the source has been reviewed line by line, and you are prepared to vendor the code rather than depend on it.
• You are ready to fork under MIT, assign a named owner, pin the version, and add it to the security review cadence — i.e., treating it as first-party code from day one.
• You have discovered existing ciphertext in the estate that was produced by this package and need to keep it decryptable during a migration. In that case the package is a bridge for a re-encryption sweep, not a forward-looking dependency.

Look elsewhere when:

• The data is production, customer-facing, or regulated. No maintainer means no CVE response.
• You need key rotation, envelope encryption, per-tenant keys, algorithm migration, or HSM/KMS integration — the package offers none of these in a defensible way.
• You need compatibility guarantees across Laravel/Lumen upgrades; archived packages drift out of support quickly, and the illuminate/*/PHP constraints likely block modern Laravel outright.
• You need vendor support, SLAs, or a security questionnaire answered.
• Your team cannot fund a full-time owner for a fork — the total cost of ownership will exceed the cost of writing thin helpers over Crypt and sodium_*.

Preferred alternatives to evaluate first: Laravel's built-in Encrypter/Crypt facade, ext-sodium directly, phpseclib/phpseclib, and a managed KMS (AWS KMS, GCP KMS, HashiCorp Vault) for key custody.

How to Pitch It (Stakeholders)

For executives (one paragraph): We evaluated yab/crypto, a Laravel cryptography helper library, as a candidate dependency for encryption and signing features. It is MIT-licensed and free, but it is archived with negligible adoption (10 stars, zero dependent projects) and no active maintainer. That means no security patching — unacceptable for code that handles keys and sensitive data. Recommendation: do not adopt. Laravel's built-in encryption and PHP's standard libsodium extension cover the same ground with first-party support, so there is no capability gap and no licensing cost either way. The only decision required is whether to invest a small amount of engineering time — likely a few days — in thin internal helpers, and to scope key rotation in from the start.

For engineering (summary): It is a facade wrapper around PHP crypto primitives for Laravel/Lumen, structurally idiomatic but architecturally redundant with the framework. Archived, unmaintained, unvalidated — no adversarial review, no production hardening, and likely blocked by composer.json constraints on modern Laravel/PHP. We are not taking the dependency. Two options: (1) implement equivalent helpers over Illuminate\Encryption\Encrypter and sodium_* — a few days of work and fully ours; or (2) fork the MIT source if its API shape genuinely saves time, in which case we own it, pin it, name a maintainer, and route it through security review. Either way, define the EncryptionService boundary first and design the key-rotation path before writing a single ciphertext — the package does not give us that. Treat this as a one-day spike and close it out; the low health score (0.3) is the correct read, and the high "opportunity" score reflects a tidy small repo rather than a capability we should adopt.