這是加密數據庫中確定性加密的有效“修復”嗎？
看來（在做了一些簡單的研究之後）加密數據庫要足夠實用以供使用，需要確定性加密，特別是對於總是為給定明文和密鑰對生成相同密文的加密類型。我知道確定性加密允許檢測相等的明文值，可能容易受到頻率分析並且缺乏語義安全性，即容易受到選擇的明文攻擊。
但是，是否可以通過以下方式最小化或消除這些缺點：
- 確保僅授權使用數據庫（以防止選擇的明文攻擊），以及
- 通過注入精心挑選（虛假）值的已知加密元組來平衡密文以轉移頻率攻擊？這些虛假值會在呈現給使用者之前從使用者端的使用者查詢結果中刪除。
當然，這可能意味著數據庫大小可能會增加一倍，但我現在想忽略它……
數據庫的加密方式完全取決於您希望能夠對其進行的查詢類型，並且其設計的安全性是根據洩漏函式L（類似於隨機預言機）來考慮的。如果伺服器無法區分洩漏函式和具有實際數據的加密數據庫，則該方案稱為L-語義安全（使其成為區分隨機預言機和 PRF 遊戲的通用版本）。
確定性加密模式（如 SIV）洩漏相等性並且僅在語義上是安全的（在傳統意義上），前提是您可以確保數據的結構方式可以防止冗餘資訊。
一個很好的例子是加密使用者資訊：使用者的 id 和使用者名將被確定性加密，以允許快速檢索這些密鑰中的任何一個，其餘資訊將被機率加密。因為使用者 id 和使用者名始終是唯一的，所以數據庫無法從通常不知道數據集的加密中獲得任何知識（除了長度/塊大小）。
但是，在某些情況下，只是告訴伺服器知道您如何對數據進行分區並沒有錯，因為無論如何它也會被 SSE（可搜尋對稱加密）方案洩露。
諸如 OPSE（保序對稱加密）之類的東西會洩露不等式（以及可選的等式），以允許伺服器對加密數據進行排序。SSE 結構通常具有更複雜的洩漏函式，但允許自由文本搜尋。
所有這些方案都已經滿足#1——搜尋需要知道密鑰。
#2 中的想法完全是針對具體情況的考慮。在大多數 SSE 方案中，允許伺服器了解有多少文件與關鍵字匹配，即使它不允許了解哪些文件，因為通常阻止它的成本太高。雖然，如果特定案例提供了有效的解決方案，那麼實施它會產生更強大的洩漏功能。