Chacha20 Laravel Package

Product Decisions This Supports

• Build vs. buy/integrate: Informs whether to adopt a pure-PHP ChaCha20 implementation versus relying on Laravel’s native encryption (Crypt with AES-256-GCM) or PHP’s sodium/OpenSSL extensions. Given this package is raw ChaCha20 only, with no AEAD, no Laravel integration, 1 star, 0 dependents, and “readme” maturity, the default product decision should be: do not make it a production security dependency without a specific protocol reason.
• Feature scoping: Supports decisions around streaming encryption, resumable uploads, or counter-seek keystream use cases only if engineering wraps it with authentication and strict nonce/counter management. It is not a drop-in replacement for Laravel’s encrypter.
• Roadmap and security hardening: Helps frame a roadmap decision to standardize on native crypto and avoid custom cryptography. If a ChaCha20 requirement appears, the roadmap item should include security review, MAC/AEAD wrapper, key/nonce lifecycle, benchmarking, and version pinning—not just package installation.
• Interoperability use cases: Relevant when a product must speak to a legacy or third-party protocol that explicitly mandates raw ChaCha20, or when a reference implementation is useful for test vectors and CI validation.
• Architecture decision: Encourages putting crypto behind an internal interface so this package can be swapped for sodium_crypto_aead_chacha20poly1305_* or another maintained implementation if requirements change.
• Use-case triage: Best treated as a reference/testing or low-throughput compatibility component. Poor fit for customer-facing encryption, high-volume data protection, compliance-sensitive workloads, or any feature where nonce reuse would be catastrophic.

When to Consider This Package

• Consider it only when all of these are true: the requirement explicitly mandates raw ChaCha20; native sodium/OpenSSL cannot be used or must be avoided; throughput is low; engineering will own the crypto integration; authentication (e.g., HMAC or Poly1305) and nonce/counter management are added separately; and a security review is planned.
• Consider it for test or reference purposes—validating ChaCha20 test vectors, building protocol compatibility fixtures, or prototyping—where production security and performance are not the goal.
• Consider it for streaming scenarios where the setCounter seek behavior and context state are genuinely useful, but only with an authenticated envelope and clear recovery semantics.
• Look elsewhere for default Laravel application encryption, authenticated encryption, high-throughput workloads, FIPS/compliance requirements, maintained long-term dependencies, or any case where the team cannot audit and own the crypto code.
• Look elsewhere if you need ChaCha20-Poly1305 AEAD specifically: use libsodium via PHP’s sodium extension rather than raw ChaCha20.
• Treat the low adoption signals—1 star, 0 dependents, fork status, readme-only maturity—as a strong warning for production adoption.

How to Pitch It (Stakeholders)

For executives: This is not a strategic dependency or a turnkey Laravel security package. It is a small, pure-PHP ChaCha20 implementation that may help with narrow protocol-compatibility or testing needs, but it is a weak default for production encryption because it provides raw ChaCha20 without authentication, performs far below native crypto, and has very low adoption. Recommend keeping Laravel’s native encryption or libsodium as the standard and requiring a clear business reason before adopting this.

For engineering: Treat it as a low-level component, not a Laravel integration. If used, isolate it behind an interface, add authentication, enforce nonce uniqueness and counter discipline, benchmark against sodium, pin the dependency, and validate with known test vectors. Do not expose raw ChaCha20 directly to product features, and plan an exit path to sodium_crypto_aead_chacha20poly1305_* or another maintained implementation.