Eloquentencryption Laravel Package

Technical Evaluation

Architecture Fit

• Use Case Alignment: Ideal for Laravel applications requiring field-level encryption at rest (e.g., PII, payment details, API keys). Fits seamlessly into Eloquent’s ORM layer without requiring application-level encryption logic.
• Security Model: Leverages RSA 4096-bit encryption (via phpseclib), aligning with modern cryptographic best practices for key rotation and data protection.
• Laravel Integration: Designed as a service provider + model trait, minimizing invasiveness. Works alongside Laravel’s built-in encryption (e.g., config['app.key']) but extends it to per-attribute granularity.
• Compliance: Supports GDPR, HIPAA, or PCI-DSS requirements by encrypting sensitive fields without exposing them in logs, queries, or dumps.

Integration Feasibility

• Laravel Version Lock: Strictly requires Laravel 12+ (PHP 8.2+). Blocker for legacy stacks (e.g., Laravel 9/10).
• Database Agnostic: Works with MySQL, PostgreSQL, SQLite (via Eloquent), but no native support for NoSQL (e.g., MongoDB).
• Key Management: Relies on Laravel’s app key for encryption/decryption. Critical: Key rotation must be handled via Laravel’s php artisan key:generate (see failure modes).
• Performance Overhead:
  • Encryption/Decryption: RSA operations are CPU-intensive. Benchmark impact on high-write workloads (e.g., >10K ops/sec).
  • Query Performance: Encrypted fields cannot be indexed (e.g., WHERE encrypted_column = 'value' fails). Mitigation: Use partial encryption (e.g., encrypt only PII, not searchable fields).

Technical Risk

Key Questions for TPM

1. Compliance Requirements:
   • Are there specific encryption standards (e.g., AES-256-GCM preferred over RSA)? If so, does this package meet them?
   • Does the team need audit logs for decryption events? This package lacks built-in logging.
2. Key Management:
   • How will master keys (Laravel’s APP_KEY) be stored and rotated in production? (e.g., AWS Secrets Manager vs. local .env).
   • Is multi-region deployment planned? RSA keys must be synchronized across regions.
3. Performance:
   • What is the expected write throughput? RSA encryption may bottleneck at scale (consider hybrid encryption: RSA for key exchange + AES for field encryption).
4. Migration:
   • How will existing encrypted data (if any) be migrated? The package does not support decrypting legacy data.
5. Monitoring:
   • Are there alerts for failed decryption attempts (e.g., corrupted keys)? The package lacks built-in monitoring.
6. Alternatives:
   • Should we evaluate Laravel Breeze/Jetstream’s built-in encryption or Tink PHP for more flexibility?

Integration Approach

Stack Fit

• Laravel 12/13: Native support with minimal configuration.
• PHP 8.2+: Required for type safety and phpseclib compatibility.
• Database: Eloquent-compatible (MySQL/PostgreSQL/SQLite). Not suitable for:
  • MongoDB/NoSQL (no Eloquent integration).
  • Legacy Laravel versions (<12).
• Dependencies:
  • phpseclib/phpseclib: v3.x (bundled via Composer).
  • No external services required (unlike AWS KMS or Hashicorp Vault).

Migration Path

1. Pre-Migration:
   • Audit sensitive fields: Identify columns requiring encryption (e.g., credit_card_number, ssn).
   • Backup database: Encryption is one-way for existing data (no decryption tool provided).
   • Upgrade Laravel: Must reach Laravel 12+ (PHP 8.2+).
2. Implementation:
   • Install package:

     composer require richardstyles/eloquentencryption
     

   • Publish config:

     php artisan vendor:publish --provider="RichardStyles\EloquentEncryption\EncryptionServiceProvider"
     

   • Apply encryption to models:

     use RichardStyles\EloquentEncryption\Encryptable;
     
     class User extends Model {
         use Encryptable;
         protected $encryptable = ['ssn', 'credit_card'];
     }
     

   • Test in staging: Validate encryption/decryption for all sensitive fields.
3. Post-Migration:
   • Key rotation: Update APP_KEY in .env and restart workers.
   • Monitor: Check for decryption failures (e.g., logs, Sentry).

Compatibility

• Pros:
  • Zero changes to database schema (transparent to queries).
  • Works with Laravel’s caching, queues, and events (data decrypts automatically).
• Cons:
  • No support for encrypted relationships: Joins on encrypted fields will fail.
  • No bulk operations: Encrypting/decrypting collections requires manual iteration.
  • No multi-tenancy: All models share the same APP_KEY (risk if keys are leaked per tenant).

Sequencing

1. Phase 1: Encrypt non-critical PII (e.g., user profiles).
2. Phase 2: Encrypt high-risk fields (e.g., payment data) after validating performance.
3. Phase 3: Implement key rotation strategy (e.g., dual-key support).
4. Phase 4: (Optional) Add monitoring for decryption failures.

Operational Impact

Maintenance

• Dependencies:
  • phpseclib: Monitor for security patches (quarterly updates recommended).
  • Laravel: Align with LTS releases (e.g., Laravel 13) to avoid compatibility drift.
• Configuration:
  • Single config file (config/eloquent-encryption.php) for key paths and algorithms.
  • No runtime tuning required (unlike query optimizers).
• Backups:
  • Critical: Ensure APP_KEY is backed up with database backups (used to decrypt data).

Support

• Troubleshooting:
  • Common Issues:
    • Decryption failures: Check APP_KEY in .env matches the key used during encryption.
    • Performance bottlenecks: Profile RSA operations with Xdebug or Blackfire.
    • Query errors: Ensure encrypted fields are never used in WHERE clauses.
  • Debugging Tools:
    • Enable ELOQUENT_ENCRYPTION_LOGGING in config to log encryption events.
    • Use dd($model->getEncryptedAttributes()) to inspect encrypted data.
• Vendor Support:
  • Community-driven: No SLA. Issues resolved via GitHub (response time: ~24–72 hours).
  • Documentation: Good for basic setup; upgrade guide is clear but lacks advanced scenarios.

Scaling

• Horizontal Scaling:
  • Stateless: Works with any number of Laravel instances (key is in .env).
  • Key Distribution: Ensure all instances have the same APP_KEY (use config management tools like Ansible/Chef).
• Performance at Scale:
  • Encryption Overhead: RSA is ~10–100x slower than AES. For high-throughput apps:
    • Cache decrypted values in memory (e.g., Redis).
    • Offload to workers: Use queues for encryption-heavy operations.
  • Database Load: No additional queries, but indexes on encrypted fields are useless.
• Multi-Region:
  • Key Synchronization: APP_KEY must be identical across regions (use a secrets manager).
  • Latency: RSA operations add ~5–20ms per field (negligible for most apps).

Failure Modes

|