- 
                Notifications
    You must be signed in to change notification settings 
- Fork 3.3k
Description
When using Always Encrypted, one cannot compare an encrypted column to a literal in SQL:
context.Patients.Where(p => p.SSN == "123-45-6789");This is because encryption must happen client-side, but the literal is unencrypted. The current workaround for this is for the user to parameterize the value, at which point SqlClient takes care of the client-side encryption:
var ssn = "123-45-6789";
context.Patients.Where(p => p.SSN == ssn);(this is called out e.g. here)
EF can do this for the user, i.e. detect comparisons of an encrypted column to a constant node, and replace the constant with a parameter. The same would apply for a few others operations (e.g. Where(b => new[] { 1, 2, 3 }.Contains(b.EncryptedColumn)). For full end-to-end support, we'd probably have to do the same thing in the update pipeline wherever we currently use literals. This would also require us to know which columns are encrypted (metadata).
In query, we could do this in a postprocessing visitor that's conditional on the connection string containing Column Encryption Setting=enabled.
Note that this is all orthogonal to EF actually setting up Always Encrypted in migrations; that's #23970.