| > What does the risk profile look like in a full leak of the encrypted database? We actually have a number of different schemes which trade leakage for performance/storage overhead/compatibility. Each one has its own type in Postgres so you just create a column with whatever type you want. The weakest (most leakage) is OPE - order preserving encryption. We use an encoding scheme that works like scientific notation so an attacker with a DB snapshot would learn relative order but not the size of the gaps between values. Its major benefit is compatibility - it works everywhere. The strongest is Block ORE - Order Revealing Encryption. A DB snapshot reveals nothing more than standard randomized encryption (IND-CPA2 semantic security).
The tradeoff is that BlockORE values are much bigger: 32-bit integer goes to 384 bytes. On Postgres its still very fast and works with standard B-trees. > If you had a column of integers are you able to order them without decrypting? Yes. For either scheme, its just an EQL function: SELECT * FROM foo ORDER by eql_v3.ord_term(x); > Check that values are the same? -- $1: encrypt(query)
SELECT * FROM foo WHERE eql_v3.eq_term(x) = eql_v3.eq_term($1); > Identify null values? NULL is just like any value for OPE/ORE - encrypt it and use that to query
-- $1: encrypt(NULL)
SELECT * FROM foo WHERE eql_v3.eq_term(x) = eql_v3.eq_term($1); NULL values can be encrypted with either scheme. Very safe to do so with the ORE scheme (fully randomized values). If encrypting strings, NULLs would reveal length but you can always pad if not leaking value length is important to your security model. In the OPE scheme, NULL would encrypt deterministically so if you expect a lot of NULLs in your data this could leak the distribution. We are working on a capability now called Leakage Tuned Domains. The goal here is not to eliminate leakage but scope it to a specific data type (e.g. birthdays) such that any leakage cannot be an advantage to an attacker. Think k-anonymisation or differential-privacy on steroids. Some links if you want to learn more:
https://github.com/cipherstash/encrypt-query-language
https://cipherstash.com/blog/fixing-a-1-in-256-bug-in-cllw-o... |