Doctrine Encrypted Query Laravel Package

Product Decisions This Supports

• Compliance & Security Roadmap: Enables encrypted query processing for GDPR, HIPAA, or other regulated environments where sensitive data must remain encrypted even during query operations (e.g., search/filtering on PII like SSNs, medical records, or financial data).
• Build vs. Buy: Avoids reinventing cryptographic query logic for Doctrine ORM, reducing dev effort and risk of vulnerabilities. Justifies investment in a niche but critical security feature.
• Use Cases:
  • Searchable Encryption: Query encrypted fields (e.g., WHERE encrypted_email LIKE '%@gmail.com') without decrypting the entire dataset.
  • Multi-Tenancy: Tenant isolation via encrypted identifiers (e.g., WHERE tenant_id = ENCRYPTED('tenant_123')).
  • Audit-Ready Systems: Logs queries without exposing raw data (e.g., "User searched for *@yahoo.com" instead of actual emails).
• Future-Proofing: Aligns with trends like confidential computing or zero-trust architectures, where data is encrypted at rest and in transit/processing.

When to Consider This Package

• Adopt if:

  • Your app uses Doctrine ORM and requires encrypted field queries (e.g., searching/filtering on encrypted PII).
  • You’re building a compliance-heavy product (healthcare, finance, legal) where partial decryption for queries is acceptable but full-database decryption is not.
  • Your team lacks cryptography expertise but needs audit-proof query logging.
  • You’re already using the aeliot/doctrine-encrypted-bundle (this package extends it).

• Look elsewhere if:

  • You need full-text search on encrypted data (consider Apache Lucene + deterministic encryption or homomorphic encryption libraries like Microsoft SEAL).
  • Your queries are complex aggregations (GROUP BY, JOINs on encrypted fields may not work without extensions).
  • You’re on a tight budget (MIT license is permissive, but support is unproven; 0 stars/dependents signal early-stage risk).
  • Your team prefers PostgreSQL’s native encryption (e.g., pgcrypto) over Doctrine-specific solutions.

How to Pitch It (Stakeholders)

For Executives: "This package lets us search and filter encrypted data in our database—critical for [compliance goal, e.g., HIPAA/GDPR]—without exposing raw sensitive info. Think of it like a ‘searchable vault’: users can find records (e.g., ‘all patients with diabetes’) without decrypting the entire database. It’s a lightweight, MIT-licensed solution that avoids costly custom dev work, with potential to future-proof our system for zero-trust architectures. Early-stage but aligns with our security roadmap."

For Engineering: *"We’re adding a Doctrine ORM extension to handle encrypted queries (e.g., WHERE ENCRYPTED(email) LIKE '%@gmail.com'). This plugs into the [aeliot/doctrine-encrypted-bundle] we’re already evaluating. Key benefits:

• No full-database decryption: Queries run on encrypted fields via SQL functions.
• Audit-friendly: Query logs show encrypted patterns (e.g., *@yahoo.com) instead of raw data.
• Low risk: MIT license, active maintenance (last release Dec 2024), and Doctrine-native. Tradeoff: Limited to simple queries (no complex JOINs/aggregations on encrypted fields yet). We’d need to validate performance with our dataset size."*

For Security/Compliance: *"This addresses [specific compliance gap, e.g., ‘ inability to search encrypted PII without decrypting the entire table’]. By using deterministic encryption for queryable fields, we retain searchability while minimizing exposure. The package generates SQL functions to encrypt/decrypt on-the-fly during queries, so:

• No plaintext in logs: Queries reference encrypted values (e.g., ENCRYPTED('ssn_123')).
• Tenant isolation: Encrypted IDs prevent cross-tenant data leaks. Caveat: We’ll need to test edge cases (e.g., case-sensitive searches) and confirm it meets our [specific compliance standard]."*