Laravel Aescrypt Laravel Package

Product Decisions This Supports

• Choosing where encryption lives in the stack. This package encodes a specific architectural bet: encryption is a database concern, not an application concern. That single decision cascades into key management, query logging, backup handling, and which teams can read the data — it's a platform decision, not a feature decision, and it deserves an ADR rather than a composer require.
• Searchable/filterable encrypted fields. The main product unlock is that WHERE, ORDER BY, and reporting queries can operate on ciphertext columns via AES_DECRYPT, which the native Laravel encrypted casts cannot do without a separate blind-index column. If the roadmap contains "let support agents search customers by email/phone" over PII that must be encrypted at rest, this pattern is a real (if imperfect) option.
• Legacy coexistence and migration sequencing. If you have MySQL data already encrypted with AES_ENCRYPT from a pre-Laravel system, this package is a bridge that lets Eloquent models read/write it without a big-bang re-encryption project. That converts a multi-sprint migration into an incremental one — a scheduling and risk decision PMs own.
• Serving non-PHP consumers. BI tools, Python jobs, and direct DB readers can decrypt without reimplementing your app's crypto. For data-platform-heavy orgs, "encryption readable by anything that can run SQL" is a genuine capability, not a nice-to-have.
• Build vs. buy for crypto plumbing. The alternative is a bespoke trait + raw SQL expressions maintained by your team. Buying here is cheap in code and expensive in risk transfer: you inherit ECB-mode characteristics, key-in-query-log exposure, and a 17-star maintainer. That trade-off should be made explicitly, with security sign-off, not defaulted.
• Compliance scoping. Useful for demonstrating "data encrypted at rest in the datastore" for internal audits where the threat model is backup theft or disk exfiltration — not where the threat model includes a DBA, a compromised app server, or query-log access.

When to Consider This Package

Consider it when most of these hold:

• You already have MySQL AES_ENCRYPT-encrypted columns, or you are acquiring/merging a system that does, and rewriting the crypto is out of scope.
• Your stack is committed to MySQL 5.7+/8.x and will be for the planning horizon (no Postgres migration on the roadmap).
• You need encrypted columns to remain queryable/sortable in SQL without maintaining a parallel blind-index pipeline.
• At least one non-Laravel consumer (BI, ETL, another service) must read the plaintext.
• Your threat model is "data at rest / stolen backups / disk-level exfiltration," and your DBA/ops staff are already inside the trust boundary.
• You can pin the version, vendor the code if needed, and accept a small-maintainer dependency for a security-adjacent component.

Look elsewhere when:

• Greenfield. Laravel's native encrypted / encrypted:array casts (AES-256-GCM, authenticated, APP_PREVIOUS_KEYS rotation) are the correct default. Adding a dependency to get weaker crypto is a net negative.
• Your threat model includes insiders, log access, or DBAs. The key material travels in the SQL statement, which surfaces in the general log, slow query log, performance_schema, replication binlogs, and APM traces. That is frequently disqualifying, and it is the single most important thing to verify before adoption.
• You need authenticated encryption or key rotation. MySQL's AES_ENCRYPT has historically defaulted to ECB and derives keys by padding/truncating — no integrity tag, deterministic ciphertext, equality leakage. If tamper-detection or rotation is a requirement, this is the wrong tool.
• You need indexed search at scale. AES_DECRYPT(col, key) = ? is a full table scan. Above a few hundred thousand rows, this becomes a latency and cost problem, and you should implement blind indexes (e.g., CipherSweet-style) instead.
• Postgres, SQL Server, or multi-database. No fit.
• You need a supported vendor. 17 stars and a single maintainer is a real continuity risk for code on the PII path. Require a fork-and-own plan or an internal owner.

How to Pitch It (Stakeholders)

To executives (30 seconds): "We have encrypted customer data in MySQL that our current Laravel app can't search, and two other systems that need to read it. This package lets us query that data directly in SQL instead of building a custom encryption layer or running a multi-month re-encryption migration. It's small and cheap to adopt, but it comes with a real trade-off: the encryption key appears in database query logs, and the encryption mode is weaker than what Laravel ships by default. I recommend we adopt it narrowly — for the legacy columns only — with a security review, a pinned version, and a plan to migrate off it if the vendor disappears. It is a bridge, not a destination."

To engineering (the actual ask): "Evaluate as a scoped adapter for existing MySQL-encrypted columns, not as the encryption strategy. Before we merge: (1) confirm the cipher mode and key handling in the source, not the README; (2) trace exactly where the key appears — general log, slow query log, binlog, APM — and confirm those are locked down or disabled; (3) benchmark AES_DECRYPT filtering at our real table sizes and index strategy; (4) verify Laravel/MySQL version support against our matrix; (5) decide fork-and-own vs. upstream dependency for a security-adjacent package with one maintainer. Any new PII column goes through native encrypted casts with a blind index — this package does not set the pattern."