像 CipherCloud 這樣的公司真的可以選擇使用同態加密嗎？
我在閱讀CipherCloud 如何進行同態加密？並且想知道：
像 CipherCloud 這樣的公司是否有一種技術上可行的方式來使用同態加密 (HE)，同時在第三方 SaaS 應用程序（例如 Salesforce）中保留全部功能？此外，是否可以在不需要修改第三方 SaaS 應用程序的情況下完成？
我相信這不是完全可能的，因為使用了“Top n”函式（例如客戶圖表）和 SQL
distinct關鍵字的常見使用。例如，假設應用程序使用本月排名前 10 位的客戶（全球銷售額）。對於 DB 查詢，它意味著類似
select top 10 customerField from sales order by orderTotalField desc. 這裡的問題是，如果我們使用 HE，2+ 個不同customerFields的客戶可能是同一個客戶，這會導致值不正確，甚至可能不是 10 個不同的客戶。讓我再詳細說明一下：HE 數據庫有一個包含 3 個欄位
customerName和dailySales日期的表。John 是銷售額最多的客戶，但具有例如 8 個 HE 等效值。該應用程序要求按客戶、按年份劃分的前十名銷售額。那麼查詢是，Select cutomerName, sum(dailySales), Year(date) from datatable group by customerName, Year(date) order by Sum(dailySales) descending。如您所見，在這種情況下，數據庫需要根據每個 的銷售額進行分組customerName，並且在本範例中將失敗。希望我在這裡很清楚，首先要確定 HE 的問題。你怎麼看，他們有選擇嗎？如果是這樣，請詳細說明:)
像 CipherCloud 這樣的公司是否有一種技術上可行的方式來使用同態加密 (HE)，同時在第三方 SaaS 應用程序（例如 Salesforce）中保留全部功能？
全同態加密理論上可以1計算任何函式。因此，如果電腦可以對明文執行任務，那麼理論上可以使用完全同態加密來對密文執行完全相同的任務。
您的懷疑似乎源於平等檢查。從您的範例中，您似乎認為由於數據庫中有兩行屬於同一使用者，因此 FHE 將無法合併這兩行的銷售額。換句話說，FHE 怎麼會知道兩個加密的 customerName 值是相同的？
答案是，FHE 計算不需要知道兩個 customerName 值是相同的。相反，它會計算一個加密位。如果它們相同，則加密位加密 1，否則加密 0。這是一個非常可行的 FHE 計算。一旦它知道那個位，它就會在位乘以dailySales 值求和。因此，如果該位為 1，則添加 dailySales 值。如果該位為 0，則不添加 dailySales 值（因為 0 乘以任何值都是 0）。
因此，給定您的表格，假設您想了解排名前 1 位的客戶。大概您有一個加密的 customerName 值表。對於每個加密的 customerName 值，您將逐步檢查 sales 表中的每個條目，計算該行的位，然後將位乘以該行的 dailySales 值。您將結果與 customerName 值一起保存。一旦您為每個可能的客戶名稱完成了此操作，您將使用 FHE 找到具有最大加密和的那個，並將其返回給使用者。然後，使用者可以解密這些值並了解誰是最大客戶。
這是一個很好的例子，是的，FHE 如何允許您計算任何函式，但這樣做的方法有時需要一些技巧。
此外，是否可以在不需要修改第三方 SaaS 應用程序的情況下完成？
一般來說，我希望答案是否定的，沒有修改就無法完成。可能有一些角落/特殊情況可能。
例如，如果數據庫中的 dailySales 值是 int32，那麼加密版本肯定不適合 int32 插槽。在這種情況下，必須修改數據庫。但是，如果數據庫最初設置為將所有內容儲存為無限大小的字元串，則可以將 FHE 加密值編碼為字元串（選擇您喜歡的方法），然後以這種方式儲存。
客戶端軟體要麼必須自己進行加密，要麼可以使用代理。所以從這個意義上說，客戶端可能必須被修改（至少指向代理）。假設您使用代理。客戶端將條目發送到代理，代理對其進行加密並將其送出給 SaaS 應用程序。
代理還必須足夠聰明才能翻譯查詢。例如，頂級客戶的查詢將無法直接在 SaaS 應用程序上執行。相反，代理必須將其轉換為對整個表的查詢，然後執行我之前描述的過程。
代理只知道客戶的公鑰，因此代理無法返回明文答案。客戶將收到必須解密的查詢的加密答案。
我想這將是必須完成的過程。
請注意，客戶端實際上不必將 FHE 加密值發送到代理。客戶端可以使用 AES 加密值，然後發送使用 FHE 公鑰加密的 AES 密鑰。代理使用該加密密鑰同態解密這些值。輸出是使用 FHE 加密的使用者值。使用這種技術，客戶端將不得不做很少的 FHE 加密。
1.我說理論上是因為FHE今天仍然不實用。