Eloquentencryption Laravel Package

Product Decisions This Supports

• Compliance & Security Roadmap:

  • Enables GDPR, HIPAA, or PCI-DSS compliance for projects handling sensitive data (e.g., PII, payment details, health records).
  • Justifies investment in security-focused features for regulated industries (finance, healthcare, legal).
  • Aligns with "zero-trust" architecture by encrypting data at rest, reducing exposure from breaches.

• Build vs. Buy:

  • Buy: Avoids reinventing encryption logic (RSA-4096), reducing dev time and technical debt.
  • Custom Build: Only consider if needing unique key management (e.g., hardware-backed keys) or multi-cloud key rotation beyond this package’s scope.
  • Alternative: Replaces manual encryption (e.g., openssl_encrypt) or Laravel’s native encrypt() (which lacks key rotation).

• Use Cases:

  • SaaS Platforms: Encrypt tenant-specific sensitive fields (e.g., credit_card_number, ssn) without per-tenant key management.
  • Legacy System Modernization: Secure existing Laravel apps with minimal refactoring (adds encryption via attributes).
  • Multi-Tenant Apps: Encrypt shared fields (e.g., user_credentials) while allowing key rotation per environment.
  • Audit/Forensics: Retain encrypted data for compliance while limiting access via key controls.

• Feature Prioritization:

  • Phase 1: Integrate for high-risk fields (e.g., payment data) to meet compliance deadlines.
  • Phase 2: Extend to logs/backups (e.g., encrypt failed_login_attempts).
  • Phase 3: Explore key rotation automation for zero-downtime updates.

When to Consider This Package

Adopt If:

• Your Laravel app stores sensitive data (PII, financial, health records) requiring at-rest encryption.
• You need key rotation without decrypting/re-encrypting all data (unlike Laravel’s native encrypt()).
• Your team lacks cryptography expertise but needs audit-proof security.
• You’re using Laravel 12/13 + PHP 8.2+ (avoids legacy compatibility headaches).
• Compliance (GDPR, HIPAA, SOC 2) demands field-level encryption beyond database-level solutions (e.g., TDE).
• You want to future-proof against quantum computing risks (RSA-4096 is future-resistant).

Look Elsewhere If:

• You need client-side encryption (e.g., encrypting data before it hits your API).
• Your stack isn’t Laravel/PHP (e.g., Node.js, Python, or non-Eloquent databases).
• You require homomorphic encryption (e.g., processing encrypted data without decryption).
• Your use case demands attribute-level access control (e.g., row-level security in PostgreSQL).
• You’re encrypting entire databases (use TDE or client-side tools like pgcrypto instead).
• Your team needs hardware security modules (HSMs) for key storage (this package uses software keys).

Alternatives to Evaluate:

How to Pitch It (Stakeholders)

For Executives (1 Slide/Paragraph):

Problem: "We’re storing sensitive customer data (e.g., SSNs, payment details) in plaintext, exposing us to compliance risks (GDPR fines up to 4% of revenue) and breaches. Current encryption methods don’t support secure key rotation, leaving us vulnerable to insider threats or key leaks."

Solution: "EloquentEncryption adds field-level RSA-4096 encryption to Laravel models with zero application changes—just annotate sensitive attributes. It’s MIT-licensed, battle-tested (used in [X] industries), and future-proofs against quantum risks. Key rotation is built-in, so we can update keys without decrypting/re-encrypting all data. This meets HIPAA/GDPR requirements while reducing breach liability."

ROI:

• Compliance: Checkbox for audits (e.g., "PII encrypted at rest").
• Risk Reduction: Limits breach impact (encrypted data is useless without keys).
• Cost: $0 (open-source); saves 6–12 months of custom dev time.
• Scalability: Works for 100 users or 10M—no infrastructure changes.

Ask: "Approve a 2-week spike to encrypt high-risk fields (e.g., credit_card, medical_history). Budget $0; ROI is compliance and risk mitigation."

For Engineering (Technical Deep Dive):

Why This Package?

• Seamless Integration: Works with Eloquent models via attributes (e.g., #[Encrypt]). No ORM changes.
• Key Rotation: Supports app:key rotation without decrypting data (unlike Laravel’s encrypt()).
• Performance: RSA-4096 is CPU-intensive but optimized for Laravel (uses phpseclib).
• Audit Trails: Encrypted fields are opaque in logs/backups by default.

Implementation Plan:

1. Phase 1 (2 weeks):
   • Add package to composer.json + configure config/eloquent-encryption.php.
   • Annotate 3–5 high-risk models (e.g., User::credit_card).
   • Test with php artisan encrypt:rotate (key rotation).
2. Phase 2 (1 week):
   • Extend to API responses (e.g., ->makeHidden(['encrypted_field'])).
   • Add CI checks for encryption coverage (e.g., "90% of PII fields encrypted").
3. Phase 3 (Ongoing):
   • Automate key rotation in Kubernetes (via secrets manager).
   • Explore hardware keys (e.g., AWS KMS) for production.

Trade-offs:

• Downsides:
  • RSA-4096 adds ~50–100ms latency per encrypted field (mitigate with caching).
  • Key management is manual (but future-proof for HSMs).
• Alternatives Rejected:
  • Custom OpenSSL: Higher maintenance risk.
  • Database TDE: Overkill for field-level needs.

Success Metrics:

• 100% of PII fields encrypted within 3 months.
• Zero incidents of decrypted sensitive data in logs.
• Compliance audits pass without remediation.

Next Steps: "Let’s prototype with the User model’s ssn field this sprint. I’ll share a PR template for review."