Laminas Crypt Laravel Package

Product Decisions This Supports

• Build vs. buy vs. use native (buy = no): This package overlaps almost entirely with what Laravel already ships. Hash facade (bcrypt/Argon2id), Illuminate\Encryption\Encrypter (AES-256-CBC/GCM with HMAC authentication), and signed URLs cover password hashing and authenticated symmetric encryption out of the box. The realistic decision this package informs is "do we port legacy crypto code or rewrite it on native primitives?" — and the answer is almost always rewrite.
• Legacy migration scoping (Zend Framework / Laminas → Laravel): The one genuinely useful decision it supports is compatibility. If an inherited app has ciphertext in the database written by Laminas\Crypt\BlockCipher or password hashes produced by Laminas\Crypt\Password\Bcrypt, this package tells you whether a read-time compatibility shim is feasible before you migrate users to Laravel's Hash facade (rehash-on-login is the standard path).
• Closing a real capability gap — carefully: Public-key and hybrid encryption (RSA + AES envelope) is the only feature Laravel does not provide natively. That is a legitimate roadmap input, but the right answer is phpseclib, libsodium sealed boxes, or paragonie/halite — not an archived package.
• Security hardening backlog prioritization: If this appears anywhere in a dependency graph, it should raise a "crypto inventory" workstream: enumerate every place keys, salts, and cipher modes are chosen, and confirm nothing is rolling its own. Crypto is the one area where a low-star, unmaintained dependency is a material risk rather than a cosmetic one.
• Roadmap: deprecation/technical-debt item, not a feature bet. Because the package is archived, the only roadmap decision it drives is when to remove it, not whether to expand on it.

When to Consider This Package

Adopt only under narrow, time-boxed conditions:

• You are decrypting or verifying data that a Laminas/Zend Framework application already produced, and a rewrite would strand existing rows or credentials. Treat it as a migration bridge with a written exit date, not a dependency.
• You need exact behavioral parity during a cutover (e.g., matching a specific bcrypt cost factor or an Argon2 parameter set) so users are not locked out mid-migration.
• It arrives transitively and you cannot remove it immediately — in which case the criterion is containment: pin the version, isolate calls behind your own interface, and audit the input.

Look elsewhere when:

• The archive status is disqualifying for anything new. "Archived" plus 36 stars plus a last release in July 2024 means no security-response guarantee. For cryptography, an unpatched CVE has no mitigation path other than emergency removal.
• You need password hashing → PHP's password_hash() / password_verify() with PASSWORD_ARGON2ID. There is no reason to add a dependency for this.
• You need symmetric encryption in Laravel → Crypt::encryptString() / encrypt(). Key rotation via APP_PREVIOUS_KEYS is already handled.
• You need RSA/hybrid or signatures → phpseclib/phpseclib (actively maintained, widely audited) or libsodium via the sodium extension.
• You need a general-purpose authenticated-encryption library outside Laravel → defuse/php-encryption or paragonie/halite.
• Compliance is in scope (SOC 2, PCI, HIPAA): an archived crypto library is an audit finding waiting to happen and will need a documented exception.

How to Pitch It (Stakeholders)

To executives: We evaluated this library and recommend against adopting it. It is archived, has minimal community traction, and duplicates cryptography that Laravel and PHP already provide and maintain. Adding it would increase our attack surface and create a compliance question without adding capability. If it is already in our codebase, we should budget a small, contained removal rather than an expansion.

To engineering: This is a Laravel-agnostic Laminas package offering password hashing adapters, authenticated block cipher encryption, and RSA/hybrid helpers. Roughly 90% of that surface is redundant with Hash and Encrypter. The ~10% that isn't — public-key envelopes — is better served by phpseclib or sodium. Because the repo is archived, there is no path to a security patch; treat any existing usage as technical debt.

Recommended path:

1. Inventory where (and whether) it is actually called.
2. For passwords, migrate to Hash with rehash-on-login — zero user friction.
3. For symmetric data, decrypt with the legacy code once and re-encrypt with Crypt behind a migration script; dual-read during the transition.
4. For public-key needs, replace with phpseclib or sodium and document the key management story.
5. Wrap any interim calls behind an application-owned interface so removal is a one-file change.

Bottom line: Do not adopt. Contain and retire. The package is competent but redundant, and its archived status makes it unsuitable for anything that touches credentials or production data.