One field. Two custodians. No complete key at rest.

The cryptographic flow

1. Project creation

   Your application receives shard K once. Silentnox retains a separately protected shard S.

2. Key derivation

   For an authorized request, K and S are combined through HKDF to derive a data-encryption key. Neither shard is the data-encryption key by itself.

3. Authenticated encryption

   AES-256-GCM encrypts the value and authenticates its integrity. The resulting self-contained blob returns to your application.

4. Runtime decryption

   Your backend submits the blob and shard K. Plaintext is returned for immediate use and is not retained by Silentnox.

What this changes

A database leak reveals encrypted blobs but not shard K or S. A Silentnox data-store leak does not reveal your project key or encrypted blobs. Compromise of one custodian alone is insufficient to decrypt a field.

This model does not protect a fully compromised application runtime that can read both request inputs and responses. Review the complete assumptions before adopting it.