Encrypter Bundle Laravel Package

Technical Evaluation

Verdict up front: do not adopt. Evaluate only as a legacy artifact or a reference implementation. Despite being routed as a "Laravel/PHP package," pierrre/encrypter-bundle is a Symfony2 bundle — a packaging format (DI container extension, compiler pass, XML/YAML service definitions, bundle kernel registration) that has no analogue in Laravel's service-provider model and no path into a modern Symfony 4+/6/7 application. It is archived, has zero dependents, and 20 stars. For a TPM, the correct framing is "is this a liability in our estate?" not "should we integrate this?"

Architecture fit

• Target runtime is Symfony 2.x on PHP 5.x. Symfony 2.8 reached end of life in November 2018; PHP 5.x and 7.0/7.1 are long past security support. The package's supported platform is outside any modern support envelope.
• A Laravel application cannot consume a Symfony bundle: Laravel has no AppKernel, no bundle registration, and no Bundle class resolution. The conceptual overlap (both are DI containers) is not binary or API compatible.
• Encryption is a cross-cutting concern that must sit under a stable interface we control (EncrypterInterface-style contract). A 20-star archived bundle is the opposite of a stable, swappable abstraction.

Integration feasibility

• composer require will almost certainly fail dependency resolution against any modern Symfony or Laravel release. Forcing it with --ignore-platform-reqs trades a clean install failure for a runtime fatal — strictly worse, because it fails in production rather than in CI.
• The realistic scope of "integration" is: none for greenfield. For legacy code that already depends on it, integration work is extraction, not adoption.

Technical risk (the deciding factor)

• Cryptographic risk is the headline. Bundles of this vintage typically wrap mcrypt_*, removed in PHP 7.2. Where the code does run, the common-era construction is CBC or ECB with a static or key-derived IV, padding without a MAC, and no AEAD. That is exactly the pattern behind padding-oracle and key-reuse vulnerabilities. We cannot certify this as a security control until an engineer reads the cipher source line by line — and even then, absence of a security policy, no disclosure channel, and no maintainer means we own any CVE.
• Abandonment risk is certain, not probable. Archived + 0 dependents + 20 stars means no upstream fixes, no community validation, no compatibility work. Every future PHP or framework upgrade becomes our problem.
• Key management is absent by design. A bundle-era "encryption service" typically exposes a single symmetric key from configuration. There is no key rotation, no key versioning on the ciphertext envelope, no KMS/HSM/vault integration, and no envelope encryption. Rotation without versioning means a re-encryption project later.

Key questions to put to the requesting team

1. What is the actual requirement — field-level at-rest encryption, tokenization, transport security, or a compliance checkbox? Most of these are better served by defuse/php-encryption, paragonie/halite, libsodium secretbox, or Laravel's built-in Crypt facade with AES-256-GCM.
2. Does this bundle already run in production anywhere in our estate? If yes, we have a migration, not an evaluation.
3. What cipher mode, IV strategy, and authentication tag does the implementation use? Has anyone read the source?
4. Which compliance regime drives this (PCI DSS 3.5/3.6 key management, HIPAA, SOC 2, GDPR Art. 32)? That determines whether a hand-rolled bundle is even admissible.
5. What is our key custody story — KMS, HSM, sealed secrets — and does this code touch it at all?

Integration Approach

Stack fit

• Laravel: incompatible. Use the framework's native Illuminate\Encryption\Encrypter (OpenSSL AES-256-CBC/GCM) or a vetted library. Do not shim a Symfony bundle into a Laravel container.
• Modern Symfony: incompatible. Symfony ships sodium-based primitives and defuse/php-encryption is a drop-in with a stable interface.
• Legacy Symfony 2.x: the only place this package legitimately lives — and only long enough to get out.

Migration path (legacy containment, if applicable)

1. Inventorize every call site and every ciphertext column/blob. Establish ciphertext format, whether an IV is stored alongside, and whether the key is single or rotating.
2. Freeze new writes through the bundle. New writes go to the target library behind our own EncrypterInterface.
3. Dual-read shim: a decorator that detects ciphertext version and routes to the legacy decryptor or the new one. This is the only place the bundle is referenced post-freeze.
4. Backfill re-encrypt in batches, idempotently, with a verification pass that asserts round-trip on a sample before and after.
5. Decommission: remove the dependency, delete the shim, delete the key from config once no legacy ciphertext remains.

Compatibility

Sequencing guidance

• If there is no production usage: close the request and redirect to a vetted library. Cost is one conversation.
• If there is production usage: treat it as a security remediation project, not a feature. Budget engineering time for the re-encryption backfill and a key-rotation runbook; schedule it ahead of the next PHP major upgrade, because that upgrade will break it regardless of intent.

Operational Impact

Maintenance

• Archived means we are the maintainers. Any fork becomes an internal project with an internal owner, an internal security review obligation, and no path to upstream a fix. That is a permanent tax on a component that provides no differentiating value.
• No compatibility work will ever land for new PHP or framework versions. Every platform upgrade is a manual patch exercise against unmaintained code.

Support

• No upstream support, no issue triage, no disclosure channel. Supportability reduces to "the one engineer who has read the source." That is a single point of failure and a bus-factor risk we should not accept for a security control.
• Documentation is a README at best. Onboarding cost is real, and the knowledge is not transferable to any library we would actually choose.

Scaling

• Symmetric crypto per record is cheap in absolute terms; this will not be the throughput bottleneck. The scaling problem is architectural: a single configured key with no rotation and no per-tenant key isolation means we cannot scale key custody, cannot support tenant-level key deletion (a real GDPR requirement), and cannot move to a KMS/HSM without rewriting the call sites.
• If encryption happens per-request in the application tier, key material lives on every app node. That is a broader blast radius than a KMS-mediated design.

Failure modes

• Hard outage on PHP upgrade when mcrypt_* disappears — the highest-probability, highest-impact failure, and it is scheduled by the platform team, not by us.
• Padding-oracle exposure if CBC-without-MAC is in use, exploitable by anyone who can submit ciphertext and observe errors.
• Unrecoverable data loss if the key is lost or rotated without a re-encryption pass — this is the failure mode that cannot be rolled back.
• Silent corruption: decryption of tampered ciphertext returning garbage rather than throwing, which pushes the defect downstream into business logic.
• Composer resolution breakage on the next lockfile regeneration, discovered mid-sprint.

Ramp-up

• Low transferable value. Time spent learning Symfony 2 bundle conventions and this cipher's quirks does not compound into anything useful. The same hours spent on libsodium/sodium_crypto_secretbox or the framework's native encrypter produce knowledge the team keeps.
• Recommended posture: a short spike to determine whether any ciphertext exists in production, then either a one-page "declined" note or a remediation epic with an owner, a backfill plan, and a decommission date. Do not add this package to the dependency tree.