Encryption Bundle Laravel Package

Product Decisions This Supports

• Encryption-at-rest architecture: This bundle forces an explicit choice between three models a PM will be asked to weigh — field-level application encryption (what this does), database-level encryption (TDE, encrypted volumes, RDS/managed Postgres), and storage-level encryption (S3 SSE-KMS). That choice determines key-management burden, query capability, compliance evidence, and the blast radius of a database compromise.
• Compliance scoping: Which data classes (PII, PHI, payment instruments, tokens, KYC documents) must be encrypted at the column level versus merely masked in the UI and API responses? This is a direct input to GDPR Art. 32, HIPAA §164.312, and PCI-DSS 3.5 control mapping — and to whether you're claiming "encrypted" in a DPA you can actually defend.
• Build vs. buy on crypto plumbing: Its real value is the Doctrine mapping layer, not the cryptography. So the question it helps settle is whether that integration layer is worth owning — vendor a bundle, adopt libsodium/defuse/php-encryption directly, or push the obligation to infrastructure. For a Laravel/Eloquent roadmap, the answer is almost always "a native cast plus KMS," which is a week of work and stays under your license.
• Searchability trade-off (the one that bites product later): Encrypted fields are effectively unqueryable — no WHERE, ORDER BY, LIKE, unique constraints, or reporting. Adopting this pattern forces a decision per attribute: stay plaintext, or move to a blind-index column (deterministic HMAC of the normalized value). That constrains future feature requests like "let support filter by email domain" and should be documented before any field is encrypted, not after.
• Multi-tenancy and data residency: Per-entity key association opens the door to per-tenant key isolation — a roadmap item that is very expensive to retrofit once schemas ship.
• Retention, deletion, and offboarding commitments: Any customer-facing SLA or DPA promising crypto-shredding on deletion, or key rotation without downtime, depends on whether the chosen approach supports re-wrapping keys. That is not a commitment to make casually in a sales cycle.

When to Consider This Package

Consider it only if:

• You are on Symfony with Doctrine ORM. Despite how it gets categorized as a "Laravel/PHP package," this is a Doctrine-integrated Symfony bundle: it hooks Doctrine lifecycle events and touches Symfony Form/Validator/Config. Under Laravel/Eloquent it is not usable without introducing Doctrine via a bridge, which means a dual-ORM persistence layer for one feature. That alone typically ends the evaluation.
• You need transparent, attribute-driven encryption of discrete entity fields and encrypted file attachments alongside entities, with minimal boilerplate — a two-day spike on a Symfony codebase.
• Your deployment is internal or SaaS with no redistributable artifact, which keeps GPL-2.0 obligations containable.

Look elsewhere if:

• You're on Eloquent. The Laravel-native alternatives — an EncryptedCast on libsodium secretbox, model observers, or a mutator with envelope encryption — are cheaper, testable, and yours. Eloquent has no hydration-stage interceptor, so the bundle's core mechanism has no direct analogue anyway.
• License friction exists. GPL-2.0 is copyleft on distribution. If you ship an on-prem appliance, an SDK, or a packaged product, legal will likely block it. Most SaaS survives; most packaged software does not.
• Adoption risk matters. Two stars, zero dependents, single maintainer, dormant repo, no CVE watch. You are effectively forking. For cryptographic code, owning the fork — including PHP 8.2+/Doctrine 3.x/Symfony 6+ compatibility patches — is a materially different risk than owning a logging helper.
• You need KMS/HSM-backed keys, envelope encryption, per-tenant custody, or audited key handling. Its key model is file/config-based, and the default stores key material in the same database as the ciphertext — weak protection against the DB-dump threat you're most likely defending against.
• You need to query, sort, or report on encrypted data, or you have high write throughput where per-field encrypt/decrypt on every hydration becomes measurable latency and CPU.
• You need a rotation story. Re-encrypting a table is a bespoke, resumable, idempotent background migration project; it isn't a config flag.

How to Pitch It (Stakeholders)

To executives: This is a small, single-maintainer Symfony/Doctrine library that encrypts individual database columns and attached files before they reach storage. It solves a narrow but real compliance problem — "if someone walks off with a database dump, this PII is unreadable" — without changing database platforms, and it's a useful design reference for how to do that. It is not a Laravel package, it is GPL-2.0, and it has essentially no adoption, which means adopting it means owning cryptographic code we'd have to maintain, upgrade, and audit ourselves with no upstream security response. Recommendation: do not adopt as a dependency; treat it as a pattern source. The compliance outcome we need is better delivered by managed database and storage encryption plus a small first-party encryption cast built on libsodium and backed by our cloud KMS — roughly a week of engineering, fully under our license and control, with no bus factor — plus a documented decision on which fields can never be filtered or sorted.

To engineering: The bundle's only real contribution is Doctrine lifecycle hooks that transparently encrypt on persist and decrypt on hydrate, plus an encrypted-file abstraction using a hybrid RSA+AES scheme and per-entity key association. That is not a large amount of code, and the parts we would actually depend on — cipher choice, nonce handling, key derivation, rotation — are precisely the parts we should not inherit from an unmaintained third party. A credible Laravel-native equivalent is 200–400 lines: an EncryptedCast using secretbox or AES-256-GCM, a per-record data key wrapped by a KMS/Vault master key and cached per request, a Flysystem decorator so file encryption streams identically on S3 and local, and blind-index columns where search is required. Where we should learn from it: the hybrid file-encryption approach, per-tenant key scoping, and explicit scoping of encrypted fields. Where we must do better: keys must live in KMS, not the application database; we need a tested key-restore and rotation runbook before the first field ships; and we should pilot on one low-risk PII field behind a flag to verify serialization, log redaction, and queue payloads before backfilling. If we were a Symfony/Doctrine shop with a hard field-level encryption mandate and no KMS budget, it's a reasonable two-day spike — we are neither.