Encrypter Bundle Laravel Package

Getting Started

• This is not a Laravel package. pierrre/encrypter-bundle is a Symfony2 bundle from the Symfony 2.x era. It ships a Bundle class, an Extension, and DI config — none of which Laravel's service container autoloads. Before writing any code, decide whether you're actually consuming it inside an old Symfony app (where it's a drop-in) or trying to graft it into Laravel (where you should almost certainly use Laravel's built-in Crypt facade instead).
• Check the status first. The repo is archived and has ~20 stars and zero dependents. Treat it as a reference implementation, not a dependency you can build a product on. Confirm the PHP version it targets against your runtime — it predates PHP 7.2's removal of mcrypt, and OpenSSL-based ciphers may be the only ones still functional.
• Where to look, in order:
  1. DependencyInjection/Configuration.php — tells you the exact config keys (typically a key, plus cipher/mode/algorithm-style options).
  2. DependencyInjection/PierrreEncrypterExtension.php — shows the service ID it registers and how the key is injected.
  3. The encrypter service class itself — shows the encrypt/decrypt method signatures and whether it base64-encodes output.
  4. README.md — the config example is usually the fastest path to a working setup.
• Minimal Symfony wiring: register the bundle in AppKernel.php, put the key in parameters.yml (never committed), point pierrre_encrypter.key at it, then inject the service (commonly pierrre_encrypter.encrypter) into whatever needs it.
• First use case: encrypt a single field (an API token, a stored secret) before persisting and decrypt on read. Test round-tripping encrypt() → decrypt() with a known key before wiring it into anything real; this immediately tells you whether the cipher your PHP build lacks is the one it defaults to.

Implementation Patterns

• Service injection over static calls. Define the encrypter as a constructor dependency on the class that needs it, so you can swap in a test double and so the key comes from config rather than a global. This is the one pattern worth copying verbatim into a Laravel codebase.
• Encrypt-then-persist via a Doctrine listener. The canonical use is a prePersist/preUpdate subscriber that encrypts designated fields and a postLoad that decrypts them. Keep the field list in one place (an entity attribute or a config map) so you don't scatter encrypt() calls across controllers.
• Keep ciphertext in a text/LONGTEXT column, not a fixed-width one. Base64-encoded output plus IV and padding grows unpredictably; sizing columns as VARCHAR(255) is a classic truncation bug.
• Separate the key from the code path. Load the key from environment/parameters and inject it. If you're porting the idea to Laravel, this maps directly to config('app.key') and the Crypt facade — the bundle's value here is mostly as a pattern reference.
• Wrap it behind an interface. Define your own EncrypterInterface with encrypt(string): string / decrypt(string): string and have the bundle's service implement or be adapted to it. When the bundle inevitably can't be upgraded, you replace one adapter instead of hunting call sites.
• Version your ciphertext. Prefix stored values with a scheme tag (e.g. v1:) so a future key rotation or cipher change can be handled by branching on the prefix at read time. The bundle gives you raw bytes; the versioning is your job.
• In a Laravel context, don't reimplement. Use Crypt::encryptString() / decryptString() for payloads, Hash::make() for passwords (never the encrypter), and encrypted casts on Eloquent models. The equivalent "bundle" is already in the framework.

Gotchas and Tips

• Archived means no CVE fixes. The package is unmaintained. If it depends on mcrypt (likely given its Symfony2 vintage), it will hard-fail on PHP 7.2+; if it uses OpenSSL with a CBC-mode cipher, it may lack authentication (no MAC/AEAD), leaving ciphertext malleable. Verify which mode you're on before trusting it.
• The default cipher is the trap. Old encrypter bundles often default to something like rijndael-256/cbc that no modern PHP build provides. Set the cipher explicitly to something your runtime actually supports (e.g. aes-256-cbc, ideally aes-256-gcm) and test decrypt with the exact same config.
• Keys are usually raw, not base64. Unlike Laravel, which expects a base64 APP_KEY, this bundle likely wants the literal key string. Mismatched encoding is the number-one cause of "decrypts to garbage" — the operation succeeds but returns wrong bytes, so it fails silently rather than throwing.
• No integrity check means garbage-in-garbage-out. With CBC and no MAC, decrypting a tampered or wrong-key value returns junk rather than an error. Always add an HMAC or use an AEAD mode, and validate a known plaintext on boot to fail fast on key misconfiguration.
• Debug by asserting the round trip, not by eyeballing ciphertext. Ciphertext is non-deterministic if an IV is used; two encrypt() calls on the same input will differ and that's correct. Write a test that asserts decrypt(encrypt($x)) === $x and a second that asserts a wrong key throws or returns a distinguishable failure.
• Config quirks to watch: the DI extension may register the service under a non-obvious ID (check the extension, don't guess), and the key parameter may be read at container compile time — meaning changing the env var requires a cache clear (app/console cache:clear).
• Extension points are thin. There's typically no pluggable cipher-provider interface; if you need key rotation, envelope encryption, or KMS backing, you'll be writing it around the service, not inside it. That's another signal to prefer a maintained library or your framework's native crypto.
• Bottom line for a Laravel dev: read this repo for the DI/config shape and the Doctrine-listener pattern, then implement the actual encryption with Crypt. Don't add an archived Symfony2 bundle to a Laravel project — you'd be pulling in a second container, an unmaintained cipher layer, and a transitive dependency risk for functionality Laravel already ships.