- Is dsbaars/chacha20 a drop-in replacement for Laravel's Crypt facade or Encrypter?
- No. This package is a raw ChaCha20 stream cipher primitive and does not implement Laravel's Illuminate\Contracts\Encryption\Encrypter contract, so it cannot back the Crypt facade, encrypted Eloquent casts, or signed URLs. Laravel's default stack already provides authenticated AES-256-CBC/GCM via OpenSSL plus sodium ChaCha20-Poly1305 on PHP 7.2+, which is faster and authenticated. Keep the framework encrypter in place and treat this as a narrow add-on capability, never a swap.
- How do I install and use dsbaars/chacha20 in a Laravel application?
- Install with composer require dsbaars/chacha20; there is no service provider, facade, config file or published assets. Instantiate ChaCha20\Cipher, call init($key, $nonce) to get a context, then call encrypt or decrypt on it. In a Laravel app the sensible pattern is binding a thin purpose-built wrapper (for example a file-cipher service) as a singleton and keeping the raw Cipher class internal rather than injecting it into controllers or models.
- Does this package support authenticated encryption (AEAD) or Poly1305?
- No. The API exposes only init, encrypt, decrypt and setCounter, with no authentication tag, no AEAD construction, no key derivation, no nonce generation and no ciphertext envelope. Output is malleable by default, so bit-flipping and truncation go undetected unless you build Encrypt-then-MAC yourself (for example HMAC-SHA-256 over the ciphertext with an independent key) and version your wire format. If you want authenticated ChaCha20 without writing that layer, use sodium_crypto_aead_chacha20poly1305_ietf_* instead.
- Which ChaCha20 variant does it implement, IETF (RFC 8439) or the original 64-bit nonce version?
- The README does not state which variant is implemented, and this must be confirmed before any interoperability work. The original ChaCha20 uses a 64-bit nonce with a 64-bit counter, while RFC 8439 uses a 96-bit nonce with a 32-bit counter, and the two produce incompatible keystreams for the same key and nonce bytes. Check the source and run RFC 8439 test vectors in CI on your PHP version, because the answer determines whether output matches libsodium, OpenSSL or a partner protocol's expectations.
- Does the package prevent nonce reuse, and what happens if I reuse one?
- Nothing is enforced; the README only warns that a nonce must not be used more than once for a particular key. Reusing a nonce with the same key XORs two keystreams together, which is a total confidentiality break rather than a gradual degradation, and it also undermines any MAC you layer on top. You own nonce allocation entirely, so use random 96-bit values or a strictly monotonic counter and never let application code call the raw encrypt method with a caller-supplied nonce.
- How does streaming encryption work, and do I need separate contexts for encrypt and decrypt?
- The init call returns a Context object that holds the algorithm's running state, so you can feed a message in chunks and keep encrypting where you left off, which suits streams, large files and chunked protocols. Because each context is independent, running encryption and decryption at the same time requires two contexts from two separate init calls. Note that decrypt is simply an alias of encrypt; the separate name exists only to signal intent.
- What does setCounter do, and can I decrypt one byte range of a large file without processing everything?
- Yes. setCounter seeks the keystream, with the counter expressed in 64-byte blocks, so you can jump to an offset and decrypt only that range instead of starting from byte zero. That random-access decryption is the capability Laravel's Encrypter does not offer and is the main reason to choose this package for large at-rest blobs or object-range reads. You are responsible for computing the correct block offset and for never reusing a key, nonce and counter tuple.
- Does it work with Laravel 10 or 11, and which PHP versions are supported?
- The library is framework-agnostic, so it runs on any Laravel version whose PHP runtime satisfies the constraint declared in its composer.json, which is what the Packagist PHP badge reflects. There is no Laravel-specific code, so framework upgrades will not break it, but you also get no framework-level support or configuration. Confirm your runtime, including PHP 8.x, is inside the supported range and that the package's CI is green on it before adopting.
- How fast is it compared with sodium_crypto_aead_chacha20poly1305_ietf_encrypt or openssl_encrypt?
- Considerably slower. The README states plainly that this is a pure PHP implementation and does not perform anywhere close to a native one, while libsodium and OpenSSL are native and also authenticated. Benchmark against your realistic payload sizes before committing: for small, infrequent decryptions the gap may be acceptable, but for bulk file encryption the overhead plus your own MAC pass usually makes native bindings the better choice.
- Is dsbaars/chacha20 actively maintained, and what should I use instead if it is abandoned?
- It is a fork of leigh/chacha20 with a single maintainer, very few stars and no dependents, so there is no ecosystem acting as a security canary and automated advisories are unlikely to ever fire for it. Have a documented fallback: for ordinary Laravel encryption use the built-in Encrypter or sodium ChaCha20-Poly1305, and for seekable keystream access look at maintained libraries or native bindings. Verify the upstream project's status and assign an internal owner before putting this on a security-critical path.