Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DRIVERS-1016 clarify decryption does not need the key ID or algorithm. #1695

Merged
merged 3 commits into from
Nov 4, 2024
Merged

DRIVERS-1016 clarify decryption does not need the key ID or algorithm. #1695

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
be180e5
indicate that decryption does not require the key ID or algorithm
kevinAlbs Oct 29, 2024
bf05ae8
more consistently use terms "In-Use Encryption", "CSFLE", and "QE"
kevinAlbs Oct 29, 2024
ca57084
format
kevinAlbs Oct 29, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
29 changes: 15 additions & 14 deletions source/client-side-encryption/client-side-encryption.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -143,19 +143,19 @@ See also:
One of the data formats of [BSON binary encrypted](../bson-binary-encrypted/binary-encrypted.md), representing an
encoded BSON document containing encrypted ciphertext and metadata.

**FLE**
**Client-Side Field Level Encryption (CSFLE)**

FLE is the first version of Client-Side Field Level Encryption. FLE is almost entirely client-side with the exception of
server-side JSON schema.
CSFLE is the first version of In-Use Encryption. CSFLE is almost entirely client-side with the exception of server-side
JSON schema.

**Queryable Encryption**
**Queryable Encryption (QE)**

Queryable Encryption the second version of Client-Side Field Level Encryption. Data is encrypted client-side. Queryable
Encryption supports indexed encrypted fields, which are further processed server-side.
Queryable Encryption the second version of In-Use Encryption. Data is encrypted client-side. Queryable Encryption
supports indexed encrypted fields, which are further processed server-side.

**In-Use Encryption**

Is an umbrella term describing the both FLE and Queryable Encryption.
Is an umbrella term describing the both CSFLE and Queryable Encryption.

**encryptedFields**

Expand Down Expand Up @@ -237,6 +237,7 @@ created_key_id = clientencryption.create_data_key("aws", opts)
opts = EncryptOpts(key_id=created_key_id,
algorithm="AEAD_AES_256_CBC_HMAC_SHA_512-Random")
encrypted = clientencryption.encrypt("secret text", opts)
# Decryption does not require the key ID or algorithm. The ciphertext indicates the key ID and algorithm used.
decrypted = clientencryption.decrypt(encrypted)
```

Expand Down Expand Up @@ -2223,17 +2224,17 @@ KMIP support in the MongoDB server is a precedent. The server supports `--kmipSe
TLS options may be useful for the AWS, Azure, and GCP KMS providers in a case where the default trust store does not
include the needed CA certificates.

### Why is it an error to have an FLE 1 and Queryable Encryption field in the same collection?
### Why is it an error to have an CSFLE and Queryable Encryption field in the same collection?

There is no technical limitation to having a separate FLE field and Queryable Encryption field in the same collection.
Prohibiting FLE and Queryable Encryption in the same collection reduces complexity. From the product perspective, a
random FLE field and a non-queryable Queryable Encryption field have the same behavior and similar security guarantees.
A deterministic FLE field leaks more information then a deterministic Queryable Encryption field. There is not a
compelling use case to use both FLE and Queryable Encryption in the same collection.
There is no technical limitation to having a separate CSFLE field and Queryable Encryption field in the same collection.
Prohibiting CSFLE and Queryable Encryption in the same collection reduces complexity. From the product perspective, a
random CSFLE field and a non-queryable Queryable Encryption field have the same behavior and similar security
guarantees. A deterministic CSFLE field leaks more information then a deterministic Queryable Encryption field. There is
not a compelling use case to use both CSFLE and Queryable Encryption in the same collection.

### Is it an error to set schemaMap and encryptedFieldsMap?

No. FLE and Queryable Encryption fields can coexist in different collections. The same collection cannot be in the
No. CSFLE and Queryable Encryption fields can coexist in different collections. The same collection cannot be in the
`encryptedFieldsMap` and `schemaMap`. [libmongocrypt](#libmongocrypt) will error if the same collection is specified in
a `schemaMap` and `encryptedFieldsMap`.

Expand Down
Loading