Encryption Bundle Laravel Package

Product Decisions This Supports

• Encrypting PII/sensitive fields at rest without losing product functionality. The v1.1.0 addition of deterministic encryption means encrypted columns can now be matched with equality lookups — enabling "find user by email," dedupe checks, unique constraints, and exact-match filters on data that previously had to stay plaintext to remain queryable. This directly unblocks decisions like "can we encrypt email/national_id/account_number?" that were previously blocked by search requirements.
• Compliance-driven roadmap items. Supports GDPR/CCPA data-minimisation commitments, HIPAA/PCI scoping arguments, and security questionnaire answers ("is data encrypted at rest and field-level?"). Useful input when prioritising a "security & compliance" epic over feature work.
• Build vs. buy on cryptography. Choosing a maintained Laravel wrapper (built on a vetted library such as CipherSweet) over a homegrown encrypt()/decrypt() + hash-lookup implementation. The deterministic mode is the piece teams usually hand-roll badly (e.g. unsalted sha256(email) blind indexes); this release lets you buy that capability instead.
• Feature gating in regulated segments. Enables sales-led commitments (enterprise, health, fintech) where prospects ask for field-level encryption before signing. Can be scoped as an enabler for a market segment rather than a standalone feature.
• Data architecture and tenancy decisions. Informs whether encrypted fields live in the primary table vs. a sidecar table, how key rotation and re-encryption migrations are scheduled, and how tenant-scoped keys are managed.
• Risk acceptance decisions. Deterministic encryption leaks equality/frequency patterns — a PM decision to document: which fields may use deterministic mode (lookup keys, low-cardinality identifiers) vs. which must stay randomised (free-text, high-sensitivity payloads). This should be an explicit policy, not an engineer's per-PR judgement.

When to Consider This Package

Consider adoption when:

• You are on Laravel and have concrete fields that are both sensitive and required for exact-match queries (login identifiers, external references, dedupe keys).
• A compliance, security review, or enterprise contract requires field-level encryption, not just disk/at-rest encryption.
• You want deterministic/blind-index behaviour without building crypto yourself — the v1.1.0 feature removes the main reason teams wrote custom code.
• Key management, cipher choice, and rotation need to be consistent across teams rather than re-implemented per model.
• You need this incrementally — encrypting a handful of columns without re-architecting the schema or moving to a separate encrypted datastore.

Look elsewhere (or scope down) when:

• Product requirements include range queries, sorting, LIKE/full-text search, or fuzzy matching on the encrypted data — deterministic encryption gives equality only; you need a dedicated searchable-encryption service or a tokenised search index.
• The threat model is disk theft or backups only — database transparent encryption may be sufficient and cheaper.
• Query performance at scale is critical: blind indexes add storage and index overhead; validate against realistic data volumes.
• The team cannot own key custody, rotation, and re-encryption runbooks — the crypto is the easy part; operational key management is the ongoing cost.
• You need certified/FIPS-validated modules or a managed HSM/KMS product; a PHP library assessment alone will not satisfy that audit.

How to Pitch It (Stakeholders)

To executives: This release lets us encrypt sensitive customer data inside the database while still being able to look records up by it — the trade-off that has historically forced us to leave fields like email and account numbers in plaintext. That means we can answer security questionnaires and enterprise/regulated buyers with "field-level encrypted" instead of "encrypted at rest," without a re-platforming project. It is a small, low-risk dependency addition (opt-in per field, no forced migration of existing data) that converts a recurring compliance blocker into a checkbox. Recommended ask: a short spike plus a written policy on which fields may use deterministic encryption.

To engineering: v1.1.0 adds deterministic encryption on top of the existing randomised mode — i.e. blind-index/equality lookup support, opt-in per attribute. Use it for lookup identifiers only; keep randomised encryption for free-text and high-sensitivity payloads. Adopt to avoid maintaining a homegrown hash-lookup scheme. Before rollout we need: a field-by-field classification, key rotation and re-encryption migration plan, index/storage impact on the largest tables, and a documented rule that no new deterministic field ships without a security review. Treat the deterministic mode's leakage profile (equal values are visibly equal) as an accepted, written risk — not a default.

Bottom line: meaningful feature, non-breaking, worth adopting for teams that need queryable encrypted fields — gated on a clear per-field policy and key-management ownership.