Encrypted Field Type Laravel Package

Technical Evaluation

Architecture fit This is not a general-purpose Laravel package. It is a Streams Platform field type addon for PyroCMS 3.x, published by the same org that maintains the CMS. Its entire value proposition is registering a new field type (encrypted) that the Streams field-type registry can resolve when a stream schema is built. In a vanilla Laravel application there is no integration surface — you would be pulling in the addon's dependency chain to reuse, at best, a few dozen lines of encrypt/decrypt logic. If the product is on PyroCMS, the fit is natural: field types are the sanctioned extension point, and encryption-at-rest for a specific field is a legitimate schema concern. If the product is on anything else, the package is irrelevant and a custom Eloquent cast is the correct answer.

Integration feasibility Mechanically simple: composer require, addon registration, then assign the field type to a stream field. The real work is not installation — it is deciding which fields get encrypted, sizing columns for ciphertext expansion, and backfilling existing plaintext. Expect the package to inherit Laravel's Crypt facade (AES-256-CBC with HMAC, base64-encoded output), which means roughly 1.4x–2x storage growth plus a random IV per value. That last point is the decision-driving one: ciphertext is non-deterministic, so encrypted columns cannot be indexed, sorted, LIKE-searched, uniquely constrained, joined on, or aggregated in SQL.

Technical risk High, and concentrated in two places. First, crypto code with zero stars, zero dependents, and no evidence of external security review is a supply-chain risk you are accepting on faith; the algorithm choice, IV handling, authentication tag verification, and error behavior on tampered ciphertext all need line-by-line review before it touches production PII. Second, lifecycle risk: PyroCMS 3 and its Streams dependency sit on an aging Laravel/PHP baseline, so this addon is pinned to a stack you will eventually have to leave. Key management is the sharpest edge — encryption is almost certainly bound to APP_KEY, meaning key rotation requires a decrypt-and-re-encrypt migration across every affected row, and key loss is unrecoverable data loss with no vendor to escalate to.

Key questions

• Which cipher and mode, and is ciphertext authenticated (MAC) on read, or does it fail open?
• Is there any key-versioning or rotation story, or is APP_KEY a permanent single point of failure?
• What happens on decrypt failure — exception, null, or silent passthrough of ciphertext?
• How are empty strings, nulls, and duplicate plaintext handled (random IV means no equality detection)?
• Does it ship a backfill path for existing plaintext values, or must that be built?
• What is the tested compatibility matrix — PHP version, Laravel version, Streams version?
• Who owns maintenance? Upstream activity and issue responsiveness are the deciding factors between "adopt" and "fork."

Recommendation: adopt only if already committed to PyroCMS 3.x and the field genuinely holds regulated data; otherwise implement an Encrypter-backed custom cast (roughly a day of work) and keep the dependency surface clean.

Integration Approach

Stack fit Assume PyroCMS 3.x on a Laravel 5.x-era runtime and PHP 7.x. Validate this against your actual composer.json before anything else — a Laravel 10/11 codebase cannot consume this without a fork and constraint rewrite. Also confirm the addon is compatible with the Streams version you run; field type registration APIs have shifted across Streams releases.

Migration path Treat the field type swap as a data migration, not a config change. Sequence it: (1) inventory candidate fields and their max plaintext length, then provision columns at ceil(len * 2) + overhead; (2) add the encrypted field alongside the existing plaintext field rather than converting in place; (3) run a queued backfill that loads each record through the ORM and re-saves so the field type encrypts on write — do not do raw SQL updates, which will bypass the field type and leave plaintext behind; (4) verify row counts, spot-check decryptability, and confirm no plaintext remains in the old column; (5) drop the legacy column only after a rollback window.

Compatibility Pin the exact commit or tag in composer.json — there is effectively no release discipline to rely on when stars and dependents are zero. If you must run on a newer Laravel, fork the addon into an internal namespace and update the service provider and field type signatures yourself; that fork becomes the artifact you maintain.

Sequencing Spike and code review first (this is a crypto dependency — the review is the gate, not the install). Then fork/pin, then backfill, then flip reads behind a feature flag with a dual-read comparison period, then cut over, then decommission plaintext. Budget the review and backfill as the long poles; the composer install is an hour.

Operational Impact

Maintenance Effectively unmaintained as a dependency you can lean on. Assume you own the code: budget recurring time for security patching, PHP/Laravel upgrade work, and periodic crypto review. This is the largest hidden cost — a 200-line addon can consume more maintenance than its size suggests precisely because it handles keys and ciphertext.

Support No community, no issue triage, no vendor SLA. Any incident — failed decryption, key rotation, corrupted rows — is resolved entirely by your team. Name an internal owner before adoption.

Scaling Per-record encrypt/decrypt cost is trivial next to I/O and will not be your bottleneck. The scaling problem is architectural: encrypted fields fall out of every SQL-side operation. Filtering, sorting, and pagination on those fields become full scans with application-side decryption, reporting and analytics tools cannot read them, and equality lookups require either a separate deterministic blind index or an exact-match hash column you maintain yourself. If product teams expect to search or segment on encrypted fields, negotiate that requirement before adoption, not after.

Failure modes

• APP_KEY rotation or loss → total, unrecoverable loss of all encrypted values; there is no recovery path.
• Tampered or truncated ciphertext → decrypt exception (verify it does not fail open by returning raw ciphertext).
• Undersized columns → silent truncation on write, permanent data corruption on read.
• Bulk imports, seeders, and raw SQL bypassing the field type → plaintext persisted in an "encrypted" column, usually discovered during an audit.
• Queue workers or additional nodes running stale env keys → intermittent decrypt failures that look like data loss.
• Backups and read replicas inherit the data but not necessarily the key — confirm key escrow separately from database backups.

Ramp-up Low for developers already fluent in Streams field types — an afternoon to understand the addon and a day to wire it up. The non-obvious cost is organizational: support, ops, and analytics staff need to be told explicitly that these fields are unsearchable and unjoinable, and that "restore from backup" does not recover data lost to a key change. Plan a short briefing alongside the rollout.