Eloquent Encryptable Laravel Package

Technical Evaluation

Architecture fit The package targets the narrowest possible seam in a Laravel application: an Eloquent trait that intercepts attribute get/set and pipes values through an encryption layer before they hit the database column. That is architecturally unobtrusive — it does not touch the query builder, connection layer, or service container, so it composes with existing models without restructuring. For a TPM, the relevant question is not "does it fit" (it does) but "does it earn a dependency slot." Laravel ships a native encrypted cast that covers single-field symmetric encryption, which means this package's addressable scope is the delta above native casting: key rotation, deterministic/blind-index search, per-field key isolation, or multi-column envelopes. That delta is unverified here and must be confirmed against source before it justifies adoption.

Integration feasibility Low technical effort, high governance effort. Integration is a trait import plus a $encryptable-style property per model; no migrations beyond widening columns (ciphertext is materially longer than plaintext — size columns for base64 overhead plus IV/tag, and for the possibility of future envelope metadata). The real cost is the decision to depend on an archived repository: adoption implies either accepting an unpatched dependency or taking on a fork. Given MIT licensing, the viable path is vendoring or maintaining an internal fork, which is a maintenance commitment, not an integration task.

Technical risk

• Unmaintained security-critical code. Encryption code is among the highest-consequence code in a stack. An archived repo means no response to upstream Laravel/PHP changes, no CVE triage, no PHP 8.x or Laravel 11/12 compatibility fixes. This alone will fail most security review gates.
• No ecosystem validation. 5 stars and 0 dependents means no adversarial review, no field-reported edge cases, no second-source bug confirmation. Bugs in an encryption layer surface as silent data corruption or plaintext leakage, not as exceptions.
• Queryability collapse. Encrypted columns cannot be used in WHERE, ORDER BY, LIKE, GROUP BY, or unique indexes server-side. Any existing query that filters on a to-be-encrypted field breaks or degrades to full-table hydration into PHP. Deterministic encryption restores equality lookups but leaks frequency patterns — a trade-off that must be an explicit, documented decision, not an implementation detail.
• Key lifecycle. Correct handling of APP_KEY rotation, re-encryption of existing rows, and dual-key read windows is where these packages typically fall short. Verify before anything else.
• Native cast overlap. If the app only needs at-rest encryption of a handful of fields, Laravel's built-in cast removes the dependency risk entirely at zero cost.

Key questions

1. Does it wrap Laravel's Crypt/Encrypter (inheriting the framework's key management and AES-256-GCM) or implement its own primitives?
2. Is ciphertext randomized (safe, unsearchable) or deterministic (searchable, weaker)? Is that configurable per field?
3. Is there first-class key rotation and a re-encryption command/queue path? What happens on read with a stale key — exception, null, or passthrough?
4. What are the declared PHP and Laravel version constraints, and do they cover the versions in our target stack?
5. Test coverage and CI status at archive time; are there existing issues describing decryption failures or data loss?
6. Does it support blind indexes for the specific fields our product filters on today?

Integration Approach

Stack fit Drop-in for any Laravel 8+ application using Eloquent. No infrastructure, queue, or storage changes required. It fits the "application-level field encryption" pattern, not the "database TDE / KMS envelope" pattern; if the compliance driver is a mandate for centralized key custody (KMS/HSM, per-tenant keys, audited decrypt calls), this package is the wrong layer and the effort should go to a KMS-backed custom cast instead.

Migration path Do not add it as a Packagist dependency. Import the source into the repo (or a private fork) behind an internal interface — a custom cast or our own trait that delegates — so the underlying library is a swappable implementation detail. Wrap the encryption call site in a single internal service (encrypt/decrypt/blind-index) and route all models through it. This keeps the door open to swap in a maintained library or native casts without touching model definitions.

Compatibility Two concrete hazards: column width (ciphertext expansion, typically 1.4–2× plus overhead; plan TEXT for long fields) and existing data (a backfill plus dual-read window is required — read plaintext if decryption fails during transition, then re-encrypt). Coordinate with reporting/BI consumers: any downstream tool reading those columns directly will see ciphertext.

Sequencing

1. Confirm the four open questions above by reading source; reject if it rolls its own crypto.
2. Prototype on one low-traffic model with a non-critical field; measure hydration cost and verify round-trip on MySQL/Postgres.
3. Security review of the vendored code; assign an internal owner.
4. Backfill + dual-read migration, then flip reads.
5. Only then expand field coverage.

If steps 1–3 do not clear cleanly, fall back to native encrypted casts for at-rest needs and a maintained searchable-encryption package (e.g. CipherSweet-based) for blind-index requirements.

Operational Impact

Maintenance The dominant cost. Archiving transfers all maintenance to us: Laravel major-version compatibility, PHP upgrades, and security patches. Budget a named owner and a periodic review cadence; treat it as internal code, not a dependency. This is the single line item that usually kills adoption at review.

Support None. No upstream maintainer, no issue triage, no release channel. Internal engineers must be capable of reading and debugging the encryption path. If the team cannot staff that, the package is disqualified regardless of code quality.

Scaling Encrypted columns are effectively unindexable. Filtering, sorting, and LIKE searches on encrypted fields either move to application-side processing (row hydration into PHP — degrades nonlinearly with table size) or require deterministic encryption/blind indexes, which reintroduce pattern leakage and must be designed per query. Plan for a data-model split: keep searchable/joins-critical attributes in plaintext or blind-indexed form, encrypt only the fields that genuinely require it. Decryption adds per-row CPU on hydration; benchmark against realistic page sizes — usually acceptable, but it becomes visible on bulk exports and reporting jobs.

Failure modes

• Key loss = permanent data loss. No recovery path exists unless plaintext is escrowed elsewhere. This is the top operational risk and needs an explicit, tested backup/escrow procedure.
• Key mismatch surfaces as decryption exceptions during model hydration — often inside serializers or queued jobs, far from the write path. Instrument decryption failures with alerting (count and model/field, never plaintext or ciphertext in logs).
• Silent corruption from double-encryption on re-save (a classic trait bug) or from write paths that bypass Eloquent (DB::table() updates, raw SQL, bulk inserts). Audit every write path to those columns.
• Backup/restore and PII in logs. Encrypted-at-rest data is still plaintext in queues, cache, error trackers, and dumps; the encryption boundary is narrower than stakeholders assume.
• Reporting/BI breakage on any tool reading those columns directly.

Ramp-up Engineer ramp-up on the API is hours — it is a trait. Operational ramp-up is the real cost: key management runbooks, rotation drills, restore-and-decrypt verification, and incident response for decryption failures. That is a multi-week enablement item owned by platform/security, not a sprint task.

Recommendation Do not adopt as a live dependency. Treat it as reference source at best: extract the pattern into an owned custom cast over Laravel's Crypt, or adopt a maintained library if searchable encryption is required. Revisit only if an internal owner is funded and a security review of the vendored code clears.