Envelope Encryption & separate Blind Index salts

[fedeisas]

Hi! I'm working on integrating CipherSweet with KMS in a Laravel multi-tenant app.

There’s no official PHP implementation for envelope encryption, but I’ve been studying the AWS Encryption SDK, particularly how it handles DEK caching:
https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/thresholds.html

From what I understand, they cache DEKs in memory via a Cryptographic Materials Manager (CMM), with configurable thresholds on message and byte counts per DEK. This improves performance by avoiding KMS calls on every operation but trades off some audit granularity—you only audit DEK encrypt/decrypt events, not individual data encryptions.

In my design, each tenant may have multiple active DEKs, and I rely on KMS key rotation to ensure forward security (DEKs are short-lived, generated with the latest version of a KMS alias). The payload (the envelope) stores the encrypted DEK, the KMS key ID, and the encrypted data.

Given PHP's short-lived nature, I plan to store active DEKs (plain and encrypted) in Redis, along with their usage counters and TTLs.

However, this approach breaks CipherSweet blind indices, since the salt is derived from the encryption key. If the key changes frequently (due to DEK rotation), the salt—and thus the blind index—changes as well.

Would it be feasible for CipherSweet to support using different keys for encryption and blind index generation?
This would allow data re-encryption under new DEKs without breaking blind index searchability.

Thanks!

[paragonie-security]

Would it be feasible for CipherSweet to support using different keys for encryption and blind index generation?
This would allow data re-encryption under new DEKs without breaking blind index searchability.

Sure, I'll revisit the base library and this provider to see if there's a more elegant solution possible.

What you can do today is designate a special "tenant" with a unique ID (which is forbidden from ever being used by your data model) as the blind index key. However, this makes the usage slightly more annoying, and I'm hesitant to provide example code rather than just update the API to make this smoother.

[paragonie-security]

Update to v0.2.0 and add this call:

const RESERVED_TENANT_ID_FOR_SEARCHING = "example-string-goes-here";
// ...
$yourMultiTenantKmsKeyProvider->setStaticBlindIndexTenant(RESERVED_TENANT_ID_FOR_SEARCHING);

You'll want to make sure nobody can set their Tenant ID to whatever you define as your const value.

[fedeisas]

Hi @paragonie-security, thanks for your reply.

Using setStaticBlindIndexTenant will mean blinding all tenants with the same salt, right?

[paragonie-security]

I'm not sure what you mean by "salt".

The way CipherSweet works is that you have a KeyProvider which vends a root SymmetricKey. This can be a static key for all fields, a context-dependent key, an AWS KMS encrypted data key (that ultimately gets unwrapped by KMS), etc. This is the level that multi-tenancy is enabled.

The root SymmetricKey is then split into a different subkey for each table, and each field of a table. This can be done at the EncryptedField level, EncryptedRow level, or EncryptedMultiRows level, but ultimately, the same logic is applied.

Separately, the root SymmetricKey vended by the key provider can also be used to derive a different key for each blind index. Similar to encryption keys, each index has a different derived key, from which the indices are derived via hashing.

When you use the new mechanism, you're basically making sure that your Blind Index derived keys are static for the same table and field names, regardless of the selected Tenant. This lets you have one set of blind indexes stored in your database for all tenants, even if their underlying encryption keys are different.

If your question about "salt" is meant to ask, "Is the derived key the same for multiple tenants?" then the answer is, "Yes". See also, the unit test for the new functionality.

The advantage of this approach is: You can write cross-tenant queries to fetch encrypted values (to later be decrypted outside of the search logic). The disadvantage of this approach is that a tenant that knows many (plaintext, blindIndex) values can reason about what data is stored for other tenants (which the attacker would reasonably not have access to the decryption key).