[SERVER-40477] mongocryptd should error when to-be-encrypted element's type does not match schema Created: 04/Apr/19 Updated: 29/Oct/23 Resolved: 21/May/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Querying |
| Affects Version/s: | None |
| Fix Version/s: | 4.1.12 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | David Storch | Assignee: | David Storch |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Operating System: | ALL | ||||||||
| Sprint: | Query 2019-05-06, Query 2019-05-20, Query 2019-06-03 | ||||||||
| Participants: | |||||||||
| Description |
|
In order to ensure that the FLE system works transparently for equality predicates against encrypted fields, we must implement the following constraints:
Taken together, these restrictions prevent a situation where users can issue a query against an encrypted field such as {ssn: {$eq: NumberInt(12345678)}} and expect matches where ssn can be any of the types {int, long, double, decimal}. One cannot build an application using FLE which queries mixed-type encrypted fields. Instead, when using deterministic encryption to ensure queryability, users must define a schema which names exactly one type for the encrypted field. Furthermore, they must write the query so that any constant in an equality predicate against the encrypted field has matching type. For instance, if a user creates a schema specifying that ssn is deterministically encrypted int, they may not run an equality query such as {ssn: {$eq: NumberLong(12345678)}}, since "long" is not the type specified in the schema. Original descriptionBSONElement equality semantics involve a logical comparison function rather than byte-wise equality. Therefore, two equal BSONElements may result in unequal ciphertext after encryption, even with the "Deterministic" encryption algorithm. If we want FLE equality to work transparently, the client should encrypt a KeyString encoding. Decryption would similarly be a two-step process in which we decrypt and then decode the KeyString. The simplest example of this is integers of different types. The integer 42 can be BSON-encoded as either a NumberDouble, NumberInt, or NumberLong. The actual bytes inside the BSONElement are different for all three cases, yet all three are considered equal. |
| Comments |
| Comment by David Storch [ 10/Jul/19 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
ravind.kumar, the encrypt.bsonType keyword does still accept an array of strings. As described by
More importantly, mixed-type schemas are perfectly legal for the random encryption algorithm. Note the following schema's use of an array for encrypt.bsonType in combination with the random algorithm:
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Ravind Kumar (Inactive) [ 08/Jul/19 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
david.storch just to confirm - I'm looking at the JSONSchema definition in the specs repo compared to the Spec Document - just wanted to confirm that bsonType no longer accepts an array of strings (specifically that there's no other server ticket we've missed somewhere that added in support for that). | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Githook User [ 21/May/19 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Author: {'email': 'david.storch@10gen.com', 'name': 'David Storch', 'username': 'dstorch'}Message: Inserts and updates will fail if the value being written to | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Githook User [ 15/May/19 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Author: {'email': 'david.storch@10gen.com', 'name': 'David Storch', 'username': 'dstorch'}Message: This is precursor work which will be built upon in a Prior to this change, we were overloading a single type, The resolved encryption info differs from the encryption | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Githook User [ 15/May/19 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Author: {'name': 'David Storch', 'username': 'dstorch', 'email': 'david.storch@10gen.com'}Message: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Nicholas Zolnierz [ 12/Apr/19 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
david.storch I've filed |