- How do I install yab/crypto in a Laravel application?
- Install it with composer require yab/crypto. On Laravel 5.5 and later the service provider and facade are discovered automatically; on Lumen you register the provider manually. Publish the config file with php artisan vendor:publish so you can set ciphers and keys. Note that the repository is archived, so verify PHP and illuminate/* constraints resolve before committing to it.
- What cryptographic operations does yab/crypto actually provide?
- It offers symmetric encrypt and decrypt helpers with configurable ciphers, one-way hashing with HMAC signature verification, and cryptographically secure random key and token generation. Everything sits behind a clean expression API instead of raw OpenSSL calls. It is a thin ergonomic wrapper, so review the source to confirm exactly which primitives are used.
- Does yab/crypto work with Laravel 9, 10, 11 and PHP 8.x?
- This is unverified and is the most likely hard stop. The package was built against older Laravel and PHP lines, and Composer resolution against modern illuminate/* constraints will probably fail. Run a short spike that installs it in a throwaway project on your target PHP version before assuming compatibility. Treat constraint validation as a prerequisite, not a nice-to-have.
- Is yab/crypto still maintained and safe to depend on?
- The repository is archived, has roughly 10 stars, zero dependents, and no CVE or security disclosure channel. That means no patches, no adversarial review, and no production hardening. For cryptography those gaps are disqualifying for customer-facing or regulated data. Most teams should treat it as pattern source material rather than a runtime dependency.
- How is yab/crypto different from Laravel's built-in Crypt and Hash facades?
- Laravel already ships Illuminate\Encryption\Encrypter with AES-256-CBC plus HMAC and AES-256-GCM, the Crypt facade, the Hash facade with bcrypt and Argon2, signed URLs, and encrypted cookies. PHP 7.2 and later also ships libsodium. yab/crypto mainly adds convenience, not capability, so it only earns a place if it exposes something core does not, such as key IDs, rotation, or envelope encryption.
- Does yab/crypto use authenticated encryption or CBC with HMAC?
- That is the first thing you must verify in the source before using it on attacker-supplied ciphertext. If the construction is CBC without a verified MAC, or if the MAC comparison is not constant time, you have padding-oracle exposure. Confirm whether the mode is AEAD, how the IV or nonce is generated and whether uniqueness is guaranteed. Also check for any residual mcrypt fallback, which was removed in PHP 7.2.
- How does yab/crypto generate random keys and tokens?
- It exposes helpers for cryptographically secure random keys and tokens, which is one of its advertised features. You must confirm the underlying source is random_bytes or libsodium rather than rand, mt_rand, or uniqid. The package cannot be trusted on that point without reading the implementation. Silent weakness in randomness is exactly the failure mode you cannot detect at runtime.
- Can I use yab/crypto in plain PHP projects without Laravel?
- Yes, the core is framework-agnostic and can be used outside Laravel, with the service provider and facade only needed for container integration. That said, the same lifecycle and security concerns apply regardless of framework. If you need the primitive in a non-Laravel codebase, consider reimplementing it on sodium_compat or openssl_* behind an interface you own.
- How do I migrate away from yab/crypto or handle data already encrypted with it?
- Use a dual-read path: decrypt legacy ciphertext with yab/crypto, immediately re-encrypt with Laravel's Encrypter, then run a backfill sweep until the legacy count reaches zero and remove the dependency. Before doing so, verify ciphertext portability across OpenSSL versions, because if the cipher and mode were not pinned explicitly, old ciphertext may not survive an OS or PHP upgrade. Keep the legacy package installed and pinned until the backfill is fully verified.
- Should we adopt yab/crypto in production or standardize on something else?
- Standardize on Laravel's Encrypter for at-rest field encryption and on libsodium for anything the framework does not cover. If a genuine capability gap exists, extract the algorithm and reimplement it behind an internal encryption service interface so you own the implementation. If adoption is mandated anyway, fork it into a private, pinned repository with a named owner and a security review cadence. That is a first-party code commitment from day one, not a routine dependency decision.