Mcrypt Compat Laravel Package

Technical Evaluation

Architecture Fit

• Legacy Laravel Compatibility: Perfect for Laravel applications running on PHP 5.6–8.x where the mcrypt extension is unavailable or deprecated. Acts as a drop-in replacement for mcrypt_* functions, enabling seamless migration without rewriting core encryption logic.
• Cryptographic Agnosticism: Supports 10/16 algorithms (e.g., rijndael-256, tripledes, blowfish) and 7 modes (e.g., cbc, ctr, ecb), making it viable for legacy systems with hardcoded mcrypt dependencies.
• Laravel-Specific Synergy:
  • Integrates with Laravel’s service container for dependency injection.
  • Can be facaded (e.g., McryptFacade) to abstract polyfill usage across the app.
  • Works alongside Laravel’s built-in encryption (Illuminate\Encryption) for hybrid systems.
• Use Cases:
  • Legacy Database Encryption: Decrypting old mcrypt-encrypted fields (e.g., AES-256-CBC keys).
  • Third-Party SDKs: Wrapping outdated libraries that require mcrypt.
  • Compliance Workarounds: Maintaining exact behavior for audited systems (e.g., PHPSECLIB_MCRYPT_TARGET_VERSION).

Integration Feasibility

• Zero-Configuration Drop-In:
  • Replace extension=mcrypt in php.ini with composer require phpseclib/mcrypt_compat.
  • No changes to Laravel’s config/app.php or bootstrap/app.php unless using a facade.
• API Parity:
  • Functions like mcrypt_encrypt(), mdecrypt_generic(), and mcrypt_get_iv_size() are 1:1 compatible.
  • Example migration:

    // Before (fails in PHP 8.x)
    $ciphertext = mcrypt_encrypt(MCRYPT_RIJNDAEL_256, $key, $plaintext, MCRYPT_MODE_CBC, $iv);
    
    // After (polyfill)
    $ciphertext = \phpseclib\mcrypt_compat\mcrypt_encrypt(MCRYPT_RIJNDAEL_256, $key, $plaintext, MCRYPT_MODE_CBC, $iv);
    

• Laravel Helper Classes:
  • Create a service provider to auto-alias functions:

    // app/Providers/McryptCompatServiceProvider.php
    public function boot() {
        if (!function_exists('mcrypt_encrypt')) {
            \mcrypt_encrypt = \phpseclib\mcrypt_compat\mcrypt_encrypt;
            // Alias other functions...
        }
    }
    

  • Or use a facade for cleaner syntax:

    // app/Facades/Mcrypt.php
    public static function encrypt($cipher, $key, $data, $mode, $iv) {
        return \phpseclib\mcrypt_compat\mcrypt_encrypt($cipher, $key, $data, $mode, $iv);
    }
    

Technical Risk

Key Questions

1. Criticality of mcrypt Usage:

   • Is this for legacy data (e.g., decrypting old records) or live transactions (e.g., payment processing)?
   • Can any mcrypt calls be replaced with Laravel’s Illuminate\Encryption (uses openssl)?

2. Algorithm Audit:

   • Does the codebase use unsupported algorithms (e.g., cast-128, gost)? If so, what’s the migration plan?
   • Are weak algorithms (e.g., des, rc2) used in production? If yes, prioritize replacement.

3. Performance Requirements:

   • Are there throughput bottlenecks (e.g., bulk encryption/decryption) where this polyfill would be unacceptable?
   • Has the team benchmarked mcrypt_compat vs. native mcrypt for their specific workload?

4. PHP Version Support:

   • What’s the target PHP version? Older versions (e.g., 5.6) may need explicit emulation.
   • Is the app running on PHP 8.2+? If so, confirm mcrypt_compat v2.0.4+ is used.

5. Testing Strategy:

   • Are there existing tests for mcrypt-dependent logic? These must be updated to account for behavioral differences (e.g., ncfb mode).
   • How will regression testing be handled for encrypted data (e.g., decrypted outputs must match legacy systems)?

6. Long-Term Roadmap:

   • What’s the end-of-life plan for mcrypt_compat? Will the team migrate to openssl/sodium post-migration?
   • Are there budget/resources allocated for a full rewrite if this becomes a blocking dependency?

7. Security Implications:

   • Does the team have approval to use deprecated/weak algorithms temporarily?
   • Is there a plan to audit and replace all mcrypt usage within [X] months?

Integration Approach

Stack Fit

• Laravel Ecosystem:
  • No Conflicts: Works alongside Laravel’s core, illuminate/encryption, and other Composer packages.
  • Service Container Ready: Can be registered as a binding for dependency injection.
  • Facade-Compatible: Ideal for abstracting polyfill usage in controllers/services.
• Dependency Graph:
  • Primary Dependency: phpseclib/phpseclib (≥3.0.36 for v2.x).
  • No Laravel-Specific Dependencies: Pure PHP, framework-agnostic.
• Alternatives:
  • For New Projects: Use Laravel’s Illuminate\Encryption (built on openssl).
  • For Performance-Critical Paths: Consider rewriting to use openssl_encrypt() directly.
  • For Unsupported Algorithms: Implement custom logic or use defuse/php-encryption.

Migration Path

1. Phase 1: Assessment (1–2 weeks)

   • Tool: Use grep or IDE search to find all mcrypt_* function calls.
   • Output: Document usage (e.g., algorithms, modes, IV handling).
   • Example:

     grep -r "mcrypt_" app/ --include="*.php" > mcrypt_usage_report.txt
     

   • Audit: Identify unsupported algorithms/modes; prioritize replacements.

2. Phase 2: Dependency Setup (1 day)

   • Add to composer.json:

     "require": {
         "phpseclib/mcrypt_compat": "^2.0",
         "phpseclib/phpseclib": "^3.0.36"
     }
     

   • Run composer update.
   • For Laravel, register the service provider in config/app.php:

     'providers' => [
         // ...
         App\Providers\McryptCompatServiceProvider::class,
     ],
     

3. Phase 3: Configuration (1 day)

   • PHP Version Emulation (if needed):

     // Before autoloading
     define('PHPSECLIB_MCRYPT_TARGET_VERSION', '5.3.0');
     require __DIR__.'/vendor/autoload.php';
     

   • Facade Setup (optional):

     // app/Facades/Mcrypt.php
     namespace App\Facades;
     use Illuminate\Support\Facades\Facade;
     class Mcrypt extends Facade {
         protected