Encrypter Bundle Laravel Package

Product Decisions This Supports

• Framework-native vs. third-party crypto (primary decision). This package is a thin convenience wrapper around PHP's openssl_encrypt/openssl_decrypt using AES-256-CBC. The decision it actually informs is "do we add a dependency to do something our framework already ships?" For Laravel the answer is almost always no — the Crypt facade / Illuminate\Encryption\Encrypter already provides AES-256-CBC with HMAC authentication and key rotation via APP_PREVIOUS_KEYS. For Symfony, sodium/Seal and defuse/php-encryption are the maintained, audited options.
• Scope of an encryption-at-rest initiative. Useful as a reference point when sizing work for encrypting PII columns, API tokens, webhook payloads, or session blobs — specifically to demonstrate that the encryption call is a one-line problem and the real cost is key management, rotation, and re-encryption of existing rows, which this package does not address.
• Dependency/supply-chain review outcome. With 0 stars, 0 dependents, a single maintainer, a NOASSERTION license file, and one release (2024-10-05), this fails a standard third-party risk gate. It supports a "build/use-native, don't buy" recommendation rather than a feature bet.
• Compliance roadmap framing. If a requirement names "AES-256" (common in GDPR/HIPAA/PCI questionnaires), this package can be cited as evidence that AES-256-CBC alone is insufficient — CBC is unauthenticated and needs encrypt-then-MAC; auditors increasingly expect AES-256-GCM or XChaCha20-Poly1305. That shapes whether we budget for authenticated encryption now or later.
• Not a candidate for a platform-wide encryption standard, a service-provider abstraction, or anything touching customer data.

When to Consider This Package

Consider it only under narrow conditions:

• You are on Symfony, not Laravel (despite the brief, the package self-describes as a Symfony bundle — verify before scoping), and
• You want a minimal, no-configuration AES-256-CBC helper for low-sensitivity internal tooling — not customer PII, not payment data, and
• You are willing to vendor, pin, and read the ~single-file source yourself, and confirm the license in writing with the author before shipping, and
• You accept that you will add your own HMAC layer and own key rotation manually.

Look elsewhere — decisively — when any of the following hold:

• You're on Laravel. Use Crypt::encryptString() / the encrypted Eloquent cast. Zero new dependencies, authenticated, key-rotation support, battle-tested.
• You need authenticated encryption (GCM/Poly1305), envelope encryption, per-tenant keys, HSM/KMS integration, or FIPS validation. Nothing here covers it; reach for AWS KMS, GCP KMS, HashiCorp Vault Transit, or libsodium.
• You need key rotation with re-encryption of historical ciphertext — a hard requirement for most real deployments and absent from this package's surface.
• You have any procurement or security review process. Zero stars, zero dependents, unclear licensing, and a single release is a bus-factor and abandonment risk you cannot justify in a design doc.
• You need a supported SLA or CVE response. There is no evidence of either.

Treat it as a code snippet to learn from, not a library to depend on.

How to Pitch It (Stakeholders)

Bottom line: do not adopt manojx/encrypter-bundle as a production dependency; use the framework's built-in encryption instead.

For executives: we evaluated a small open-source package for AES-256 encryption and are recommending against it. It duplicates functionality Laravel already provides natively (and Symfony provides through maintained alternatives), it has no community adoption or dependents, an unclear license, and a single maintainer with one release — all of which create abandonment and legal risk with no offsetting benefit. Proceeding with the framework-native path costs us roughly the same engineering effort, removes a dependency from our supply chain, and gives us authenticated encryption and key rotation for free. No roadmap change; this is a "keep the default" decision.

For engineering: the wrapper exposes openssl_encrypt/openssl_decrypt with AES-256-CBC and does not perform encrypt-then-MAC, so ciphertext is malleable unless we add an HMAC ourselves. Laravel's Encrypter already does CBC + HMAC + APP_PREVIOUS_KEYS rotation, and its encrypted cast makes column encryption a one-line change. Recommendation: standardize on Crypt for Laravel services, sodium_crypto_secretbox or defuse/php-encryption for Symfony, and push key custody to KMS/Vault. If we need this package's ergonomics, we can port ~20 lines internally and own them outright. The real work item is key management and backfilling existing plaintext columns, not the encrypt call — let's size that as its own ticket.