Read this before adopting. Encrypting field values has real, unavoidable trade-offs, and this is a foundation release — some pieces are deliberately not built yet.
Encrypted columns hold random ciphertext, so the database cannot reason about their values. Only exact-match search via a blind index is supported (see Querying). Not supported:
Contains/LIKE/ substring search.- Full-text search.
- Range queries (
>,<,BETWEEN) on encrypted fields. ORDER BYon encrypted fields.GROUP BY/SUM/ aggregation on encrypted fields.UNIQUEconstraints / foreign keys on encrypted columns.
Token / partial-match search is a possible future module, not part of this release.
- Projections can return ciphertext.
Select(x => x.Email)on an encrypted property bypasses the decryption interceptor and yields the stored ciphertext. Materialize the full entity instead. - Comparing with
==in a query never matches. UseWhereEncryptedEquals. - Raw SQL writes,
ExecuteUpdate/ExecuteDeleteand bulk extensions bypass the interceptors, so they neither encrypt on write nor decrypt on read. Not supported.
- The analyzers (
PENC001/PENC002) recognise both attribute-based configuration and the simple fluent form (.Property(x => x.Email).IsEncrypted(...)/.IsEncryptedSearchable(...)/.IsEncryptedEmail(...)), on direct member access (x => x.Email) only — notnew { x.Email }, method calls or navigation chains. - Fluent recognition is limited to the directly chained form; a property builder stored in a local variable first is not seen. There are no code fixes yet.
- They are scoped to
IQueryable(database) queries — in-memoryIEnumerableprojections are fine.
LocalDevelopmentKeyProvideris not production-grade. It derives all keys deterministically from one root key; anyone with that key reproduces every key. Development and tests only.- Azure Key Vault, AWS KMS and Google Cloud KMS ship (preview). The adapters are functional, but
their configuration and production guidance are still being stabilized. The KMS foundation (registry model,
RegistryKeyMaterialProvider, theIKeyProviderKEK seam) is in place, and theProteos.Encryption.AzureKeyVault(RSA-OAEP-256),Proteos.Encryption.AwsKms(symmetric KMSEncrypt/Decrypt) andProteos.Encryption.GoogleCloudKms(symmetric Cloud KMSEncrypt/Decrypt) adapters are shipped. Each adapter only wraps/unwraps the tenant master key; wiring it intoRegistryKeyMaterialProviderstays in the application's own configuration. See Key rotation. - No re-encryption worker yet — only the planner/service plus the batch/progress/resume value
objects (
ReEncryptBatchOptions,ReEncryptBatchResult,ReEncryptProgress,ReEncryptResumeToken). These are foundation only: they execute nothing and persist nothing.
Proteos protects the confidentiality of field values at rest: a leaked database, backup or cloud-storage copy, and a curious DBA or cloud operator without KMS access, see only ciphertext. It does not protect against a compromised application server (RCE), process memory, a compromised client, stolen credentials with KMS access, or active database manipulation (integrity is per value, not database-wide). It is not end-to-end encryption.
The threat model is the canonical source — read it for the full scope, the KMS trust model, blind-index leakage, the integrity model and the cryptographic construction.
Public preview (0.1.0-preview.3). Three sample projects ship under
samples/ — a quickstart Web API, a feature showcase console app, and a realistic CRM Web API. The README
is wired into the package, and continuous integration builds, tests and validates packaging on pull
requests and on pushes to main; there is no automated release or publish pipeline. As a pre-1.0
release, some APIs may still be refined before 1.0.