- What does philetaylor/ciphersweet-encrypt actually do?
- It is a thin integration layer around Paragon Initiative's CipherSweet library, wiring field-level encryption into your models so sensitive columns are stored as ciphertext and decrypted transparently on read. The real value is the plumbing rather than the cryptography: attribute casts for encrypt and decrypt, plus configurable blind indexes so exact-match and prefix lookups still work. Keys and index definitions live in a central config file, with per-field and per-model key separation for isolation. It works with existing schemas, so you do not need a plaintext-to-ciphertext migration before you start.
- Does this package work with Eloquent models or is it Doctrine only?
- Read the source before you install it: despite the Laravel-adjacent naming and Eloquent-flavoured overview, the repository is a Doctrine DBAL integration that registers custom column types so mapped fields encrypt on write and decrypt on hydration. That makes it a strong fit for Doctrine-based applications and a poor fit for a plain Eloquent codebase. If you are on Eloquent, implement the equivalent pattern yourself with a custom cast, an explicit blind-index column, and a query scope. Do not try to force the Doctrine type registration into Eloquent.
- How do I install and configure philetaylor/ciphersweet-encrypt?
- Pull it in with Composer and then publish or create the package's central config file, where you declare your encryption keys and the blind-index definitions for each searchable field. You then point your model attributes or Doctrine column types at those configured fields so encryption happens at the persistence boundary. Because the last release was September 2020, verify the dependency constraints before installing and expect to pin Composer versions or patch the source to get it to boot. If you cannot get a clean install, treat the package as a reference implementation rather than a dependency.
- How do blind indexes keep encrypted fields searchable?
- A blind index is a deterministic, keyed hash of the plaintext stored in its own column alongside the ciphertext, so an equality or prefix lookup can be rewritten as a WHERE clause against the index instead of decrypting every row in application memory. That is meaningfully better than naively calling Crypt::encrypt() because it preserves lookup capability without ever materialising plaintext for the database. The trade-off is that blind indexes leak equality patterns, so they should only be defined on fields you genuinely need to search. Watch for index salts or key derivations that are not pinned, since an unpinned salt silently breaks every existing lookup.
- Which Laravel, PHP, CipherSweet and Doctrine DBAL versions does it support?
- Assume nothing: the last tagged release was September 2020, which places it in the CipherSweet 3.x and Doctrine DBAL 2.x era. Since then DBAL 3.x reworked the Type API and DBAL 4.x removed Type::getName(), while CipherSweet itself went through API-breaking majors around EncryptionService, providers, backends, and SensitiveField. Run a version-matrix spike on PHP 8.1 through 8.3 before committing to anything, and budget for patching rather than expecting a clean install. There is no recent release to confirm modern framework support.
- Is this package safe to use in production?
- Treat it as high risk. It has a single maintainer, roughly one star, no dependents, and no release in about five years, which means no production bug reports, no CVE surveillance, no third-party audit, and no observable response time for issues. Crypto-adjacent code is the worst category to take on faith because the failure modes are silent, from wrong key derivation to truncated ciphertext, and the blast radius is permanent data loss or a compliance claim that does not hold. A dormant, low-traffic package with one owner is also a realistic hijack or typo-squat target. If you use it at all, pin to a commit hash, vendor the source, and own the patches.
- How are encryption keys managed, and does it support key rotation?
- The package stores key material in a central config file with per-field and per-model separation, which is useful for isolation but is not a secret manager. Confirm whether keys come from your KMS or vault or are just static strings in config before you ship anything containing PII, PCI, or GDPR-scoped data. Check whether rotation is supported through CipherSweet's multi-tenant backend or whether rotating a key means re-encrypting every affected row by hand. Plan your rotation story up front, because retrofitting it after you have millions of encrypted rows is expensive.
- What column types should my migrations use for encrypted fields?
- Use TEXT or BLOB for ciphertext and a fixed-width CHAR(64) for the blind index. A VARCHAR(255) will silently truncate ciphertext and turn a bug into unrecoverable data loss, and the failure only surfaces when you try to decrypt. Define the schema as ciphertext plus blind-index columns from day one on greenfield projects and never write plaintext at all. On brownfield projects, add the new columns as nullable alongside the legacy plaintext so you can backfill safely.
- How do I migrate existing plaintext columns to encrypted ones?
- Run it as a phased backfill rather than a big-bang cutover. Add nullable ciphertext and blind-index columns next to the legacy plaintext, dual-write so new rows are encrypted while the plaintext is retained, then backfill historical rows in bounded chunks with checkpointing so a failure does not restart the whole job. The read path should prefer ciphertext when present and fall back to plaintext, and only after the backfill is verified should you drop the legacy columns. Test the encrypt, persist, and hydrate round trip plus blind-index miss behaviour before you trust the migration.
- Should I use this package or implement the pattern directly with paragonie/ciphersweet?
- Given the dormancy and cryptographic risk, the safer route is to treat this repository as a reference implementation and reimplement its roughly one to two hundred lines of type registration and query building in-house against a pinned paragonie/ciphersweet. You get the same architecture, ciphertext columns plus blind indexes, but with a maintainer who is actively watching for CVEs and a test suite you control. The package is worth reading and the pattern is worth stealing; the dependency is not worth taking. For Eloquent codebases the equivalent is a custom cast plus an explicit blind-index column and query scope.