Encryption Bundle Laravel Package

Technical Evaluation

Verdict up front: Do not adopt sidus/encryption-bundle as a dependency. Leverage it as a design reference and a decision-forcing artifact for our encryption-at-rest roadmap. The bundle's contribution is the Doctrine integration layer, not the cryptography — and we do not run Doctrine.

Architecture fit

• It is a Symfony bundle wired into Doctrine ORM lifecycle events (postLoad/prePersist/preUpdate subscribers) plus an EncryptionKey entity that stores key material alongside ciphertext. There is no Eloquent analogue: Laravel has no hydration-stage interceptor, and casts/observers/mutators cover different lifecycle points and miss DB::table(), chunked iteration, and raw query results uniformly.
• Making it fit a Laravel app means adopting Doctrine ORM (via laravel-doctrine/orm) for a single feature — a dual-ORM persistence layer and a large architectural imposition for a narrow control.
• The default key model (key rows in the same database as the ciphertext) is weak against the primary threat we care about, a database or backup dump. That alone limits its value as a shipped solution.
• What is worth lifting: transparent field-level encryption semantics, per-entity key association, and the hybrid RSA+AES approach for encrypted file attachments.

Integration feasibility

• As a direct dependency: low. Symfony Config/Form/Validator graph, PHP 5.6/7.x-era and Doctrine DBAL/ORM 2.x assumptions, near-certain incompatibility with PHP 8.2+/Doctrine 3.x/Symfony 6+.
• As a pattern source: high. The Laravel-native equivalent is roughly 200–400 lines: sodium_crypto_secretbox (or AES-256-GCM) payload encryption, envelope encryption with per-record data keys wrapped by a KMS master key, exposed as a custom cast; a Flysystem decorator for file encryption; a deterministic HMAC blind-index column where searchability is required.

Technical risk

• License: GPL-2.0. Internal SaaS use that never distributes the software is generally defensible; any on-prem appliance, SDK, or redistributable artifact forces GPL on surrounding work. Legal review is a gate, not a formality — and it applies to copied source, not to independently written implementations of the pattern.
• Abandonment: 2 stars, 0 dependents, single maintainer, health score 0.13. No CVE watch, no advisories, no issue triage. Adoption equals forking, and for cryptographic code that is a categorically different risk than forking a logging helper.
• Semantics ceiling: decryption at hydration puts plaintext in every model instance, toArray(), JSON responses, logs, queue payloads, and caches. Non-deterministic ciphertext breaks equality queries, unique constraints, sorting, LIKE, and reporting.
• Rotation: no evident envelope or re-wrap story; re-encrypting a table becomes a bespoke, resumable migration project.

Key questions for stakeholders

1. Threat model: DB dump, backup leakage, insider DBA, or regulatory checkbox? This decides whether column-level encryption is the right control versus TDE plus KMS.
2. Distribution: SaaS-only, or does anything ship to customer infrastructure? This settles GPL.
3. Do we run Doctrine anywhere today? If no, the bundle is eliminated on architecture alone.
4. Regime: GDPR Art. 32, HIPAA §164.312, PCI-DSS 3.5 — and does it mandate customer-managed keys or rotation SLAs?
5. Query needs: must support filter, sort, or report on these fields? If yes, blind indexes enter scope now, not later.

Integration Approach

Stack fit

• Proceed with the bundle only in the narrow case of Laravel with Doctrine already adopted and a team fluent in Doctrine events — and even then, vendored, pinned, and patched as a stopgap with a documented exit.
• For the default Laravel/Eloquent stack: no adoption; reimplement the pattern. The bundle is our specification, not our code.

Migration path

1. Extract the design, not the source: hybrid encryption, per-record data keys, key-per-tenant or key-per-entity scoping, master key held in AWS KMS / GCP KMS / Vault Transit.
2. Implement EncryptedCast on Laravel custom casts with libsodium secretbox; wrap data keys with the KMS master key and cache the unwrapped key per request.
3. Encrypt files at the storage driver boundary (Flysystem decorator) so S3 and local behave identically and streaming is preserved.
4. Add deterministic blind-index columns (HMAC of normalized value) for any field that must be filtered — and document that encrypted columns are otherwise unqueryable.
5. If Doctrine is unavoidable, pull the bundle via a Composer VCS/path repository, pin the commit, and patch compatibility locally — never resolve it unguarded from Packagist.

Compatibility

• Assume the bundle will not install cleanly on PHP 8.2+/Doctrine 3.x/Symfony 6+. Budget for a compatibility patch set (return types, deprecated DBAL APIs, compiler-pass signatures) if we ever vendor it.
• Legal sign-off on GPL-2.0 before copying any source, including "just a few classes." Copying the pattern into fresh code avoids derivative-work ambiguity; copying files does not.

Sequencing

• Week 1 — decision gate: threat model, licensing review, build-vs-adopt call. Everything downstream is contingent.
• Week 2 — spike: native cast against one low-risk entity, non-production, with hydration-overhead measurement.
• Weeks 3–4 — key management: KMS integration, key-rotation runbook, blind-index design if required.
• Week 5 — pilot: one PII field in production behind a feature flag; verify API serialization, log redaction, and queue payload handling.
• Week 6+ — backfill: batched, idempotent re-encryption job; expand entity by entity.

Operational Impact

Maintenance

• Zero upstream maintenance and no release cadence. If adopted, we own the fork permanently, including PHP upgrades and crypto-relevant fixes.
• 0 dependents means no ecosystem signal: no third-party patches, no blog posts, no Stack Overflow corpus. Every problem is first-principles work.
• GPL hygiene: internal modifications avoid disclosure obligations but still require repo-level license tracking, especially around any redistributed artifact.

Support

• No vendor, no SLA, no commercial backing; escalation lands on our own platform and security engineers.
• A production decryption incident has no external escalation path — assign named ownership before rollout.
• Mandate a security review of the integration; cryptography is not a component the team should self-certify.

Scaling

• Per-row decryption cost on every hydration; RSA-per-row is prohibitive, so the hybrid path matters. Profile at realistic row counts.
• Key lookups must be request-cached or the key table becomes an N+1 hotspot on every list endpoint.
• Ciphertext expansion (base64 + nonce + tag) inflates rows and indexes by roughly 33–40%; budget storage and index size.
• Rotation is O(rows) and requires a resumable, idempotent re-encryption job.
• Whole-file buffering will hit memory limits on large uploads — stream instead.

Failure modes

• Lost or mismatched key: data is unrecoverable, not degraded. Requires KMS backup, key escrow, and a rehearsed restore drill before the pilot.
• Corrupted ciphertext: throws at hydration and can fail an entire list endpoint or queue batch — needs per-field error handling and a quarantine path.
• Plaintext leakage: the dominant real-world failure. Decrypted values leak through toArray(), logs, exception traces, cache, and queue serialization unless redaction is designed in.
• Blind-index drift: normalization changes silently break lookups on encrypted fields.

Ramp-up

• Expect 2–3 days of source reading to understand the pattern; there is no documentation corpus or community to lean on.
• Our own design doc — threat model, field inventory, key hierarchy, queryability constraints — is the onboarding artifact, not the upstream README.
• Front-load product alignment on the searchability trade-off so future "let support filter by email domain" requests are answered by a blind index, not a schema migration.