- Is kitlabs/kit-crypt-bundle a Laravel package?
- No. Despite being marketed for Laravel and PHP apps, it is a Symfony bundle whose integration surface is the Symfony kernel: a Bundle subclass, a DI Extension with a Configuration tree, compiler passes, and YAML/XML service definitions. Laravel's equivalent hooks are a ServiceProvider registered in bootstrap/providers.php, and nothing in this package participates in Laravel's container, config repository, facades, or deferred-provider model. Using it in Laravel means writing your own adapter, which removes the only thing the bundle layer actually provides.
- Can I install kitlabs/kit-crypt-bundle in a Laravel 11 or 12 application?
- Composer may resolve it, but the package registers no Laravel service provider, so nothing is auto-discovered or wired into the container. You would end up instantiating the underlying cipher classes directly, which is where the framework-specific value disappears. Check the declared php and symfony/* constraints and confirm composer require resolves cleanly on PHP 8.2 and 8.3 before spending time on it.
- What ciphers and algorithms does kit-crypt-bundle support?
- The advertised inventory is largely deprecated: DES (56-bit), 3DES (Sweet32, 64-bit block), RC2 and RC4 (both broken), IDEA, and DSA. DSA is a signature algorithm, not an encryption algorithm, so its presence signals imprecise crypto design. Modern authenticated modes such as AES-GCM, CCM, and ChaCha20-Poly1305 are not called out as first-class options. The set suggests the package targets pre-2010 interoperability rather than protecting new data.
- Does kit-crypt-bundle use authenticated encryption?
- There is no evidence of AEAD being a first-class mode in the package. Unauthenticated CBC or ECB invites padding-oracle and bit-flipping attacks unless the caller applies an HMAC envelope themselves, which pushes cryptographic correctness onto application developers. Laravel's built-in encrypter already ships AES-256-CBC with an HMAC or GCM, so you would be downgrading security by switching.
- How does key management and key rotation work in this package?
- Keys and ciphers are supplied through configuration values, with no KMS or HSM integration, no envelope encryption, and no key-version identifier embedded in the ciphertext. Rotating keys therefore requires a hand-designed, full re-encryption migration across every stored record. For Laravel work, prefer a versioned key ring with explicit key IDs in the envelope so old ciphertext stays decryptable.
- What should I use instead of this package in a Laravel app?
- Use Illuminate\Encryption\Encrypter, which ships with Laravel and provides AES-256-CBC with HMAC or AES-GCM, configured through APP_KEY. For libsodium use sodium_crypto_secretbox, and for RSA or DSA use phpseclib/phpseclib v3 rather than a thin wrapper. If you genuinely need legacy DES/3DES/RC2 interop, isolate it in a small adapter over openssl_encrypt and openssl_decrypt and plan to delete it.
- Is kit-crypt-bundle safe to use in production?
- Adoption is near zero, around 5 stars and 0 dependents from a single-vendor org, with no visible SECURITY.md or CVE process. Crypto is the one dependency category where low adoption is disqualifying rather than merely inconvenient, because a vulnerability would have no coordinated disclosure path and no downstream community to have already found it. Runtime drift compounds the risk: OpenSSL 3.x moved DES, RC2, and RC4 into the legacy provider, and mcrypt was removed in PHP 7.2, so behaviour varies by host and openssl.cnf.
- Can I use it to decrypt legacy DES or 3DES data during a migration?
- That is the one legitimate use case, and even then the bundle layer adds no value inside a Laravel app. Instantiate openssl_decrypt or phpseclib directly in a roughly 150-line adapter, scope it for deletion once re-encryption to AES-GCM with a versioned envelope is complete, and verify the OpenSSL legacy provider is enabled on every host. Keep the adapter security-reviewed and test it against known-good ciphertext fixtures.
- Is the core framework-agnostic, so plain PHP projects can use it?
- Yes, the underlying crypto helpers do not strictly require Symfony, so plain PHP projects can call them. But the reusable part is a thin wrapper over OpenSSL or phpseclib primitives you could call yourself in a few lines. The Symfony-specific convenience, defining keys and ciphers once and letting the container wire everything up, is exactly what does not port to Laravel.
- How do I test encryption code if I do adopt this package?
- Round-trip tests where decrypt(encrypt($value)) equals the original are table stakes. Add tamper-detection tests that flip a byte of ciphertext and assert a failure, plus cross-version tests that decrypt ciphertext produced by older keys. If those tamper tests pass silently, the package has no authentication tag and you should stop before shipping it to production.