CipherCloud 是如何做同態加密的？
許多文獻和最新論文表明，同態加密仍然不實用。
CipherCloud是如何做到這一點的？有人有想法嗎？他們的網站沒有提供太多關於他們的系統如何工作的資訊。
我找不到任何指向同態加密的證據。我能找到的是確定性加密和格式保留加密的不同組合。可能還有一個保持秩序的變體，但我找不到任何描述它的材料。
本文基於 CipherCloud 網站CipherCloud 雲安全學習中心 - 特色內容上發布的材料。CipherCloud 指出，實際產品具有額外的加密功能，可提供更強的安全性，並且不會受到所列弱點的影響（請參閱 CipherCloud 響應部分）。
材料 1：他們的白皮書在 Salesforce、Force.com 和 Chatter 中保護您的客戶數據的最佳實踐第 10 頁的螢幕截圖：
$$ image removed due to DMCA request $$
**描述：**此螢幕截圖在三列中描述了聯繫方式（姓名、地址、電話等）。
- 第一列顯示了決定如何加密不同欄位的策略。對於大多數欄位，這是“AES Crypto Encryption”，對於某些欄位（例如電話號碼），它是一種特殊的加密形式，例如“電話號碼加密”。
- 第二列顯示明文（“授權使用者所見”）
- 第三列密文（“As seen by Unauthorized Users”）
**分析：**當一個欄位由幾個部分（比如
firstname和lastname）組成時，它們會將其拆分為這些部分並單獨加密它們。一些重要的欄位，例如“年收入”根本沒有加密，可能是因為他們需要在計算中使用它。
名稱和地址的加密保留了單個單詞的長度和空格的位置。單詞之間有特殊的標籤，似乎標記了加密的部分和單獨的標記。
保留長度強烈暗示確定性加密，支持搜尋也是如此。理論上，可以對不同的記錄使用不同的隨機數，但我認為這不太可能，因為在這種情況下很難保留搜尋索引。
材料 2：同一白皮書中的功能列表（第 11 頁）：
加密選項：AES-256、功能保留加密、長度限制加密等。能夠逐個欄位選擇
分析：在材料 1中已經觀察到相同長度的加密。推測保留功能搜尋和排序。可能可以選擇在每個欄位的基礎上保留哪些功能。材料 3將展示一種允許搜尋但似乎不保留排序的加密形式。
材料 3：2:30 和 3:00 左右的CipherCloud Connect AnyApp 展示影片：
$$ screenshot omitted due to DMCA request $$
**描述：**這顯示了一個典型的留言板，它是 yammer Web 應用程序的一部分。有兩個打開的視窗顯示相同的執行緒。一個顯示加密消息（正如 yammer.com 伺服器看到的那樣），另一個顯示通過 CipherCloud 訪問時看到的純文字形式。郵件正文已加密，使用者名和發佈時間未加密。加密的消息是亞洲字元和 ASCII 字元的混合體。
分析：
明文單詞和密文令牌之間有明確的對應關係。每個記號以 開頭
zqx1，以 結尾0j1xqz並對應一個單詞。標點符號根本不加密。在明文中多次出現的單詞（例如
meet,to）want在密文中顯示為相同的標記。詞
new和will更有趣。它們以小寫和大寫形式出現。的加密形式New可能看起來像zqx1賓翡祀徠鈞祁記勤机琦芸稶70j1xqz1和加密形式new像zqx1賓翡祀徠鈞祁記勤机[linebreak]20j1xqz2。所以我假設令牌的第一部分以不區分大小寫的形式對單詞進行編碼，第二部分提供大小寫資訊。席德在他的文章中也發表了同樣的看法。這種加密形式允許他們在影片中展示的不區分大小寫的搜尋，其中搜尋
apac出現的消息包含APAC因為單詞的開頭是相同的，無論大小寫如何。這看起來像是小寫單詞和標記的第一部分之間的 1:1 映射。令牌的第一部分似乎具有 9 個亞洲字元的恆定大小。給定大量這樣的字元，這足以編碼 128 位或一個 AES 塊。因此，一種可能的實現是在 ECB 或 CBC 模式下使用 AES，並使用常量 IV 加密單個塊。但這一段純粹是推測，無法從我們所做的有限觀察中得到證明。
這種方案的一個固有弱點是它不提供語義安全性。如果同一個詞在不同的地方被加密，攻擊者可以看到在兩個地方都使用了同一個詞。如果他能認出其中的一個，他自然也會知道另一個。
攻擊者還可以對令牌進行某種詞級頻率分析。一旦部分密文被恢復，已知單詞將作為進一步猜測的上下文。一旦超過某個知識門檻值，這應該可以恢復大多數單詞。所以它本質上是為了防止攻擊者學習任何（密文，明文）對，即使是無害的消息。引用公共材料或儲存稍後將發布的草稿也是非常危險的。
類似的非確定性方案
上述方案本質上是一個字級替換密碼。經典替換密碼通常使用單個字母（或少量固定數量的字母）作為替換單元。諸如 AES 之類的現代分組密碼通常允許使用整個單詞作為替換單元，這在沒有電腦的情況下有點難以做到。
那些早期的替代密碼與上述方案有相似的弱點（字母之間的 1:1 映射、確定性加密和頻率分析）。當然，對於短/字母單元，這些弱點比長/單詞單元要明顯得多。
用於減少這些弱點影響的一種技術是對每個明文單元進行多種可能的替換，並在加密期間隨機選擇一個。這種技術稱為諧音替換。這種技術顯然也可以應用於字級替換密碼。
當一個詞有 n 個可能的密文時，仍然可以通過對加密數據觸發 n 個單獨的搜尋並合併結果來進行搜尋。這會將 1:1 映射轉變為 1:n 映射，使加密變得不確定，並且根據選擇的機率分佈，頻率分析也可能不太有效。當然，這樣的組合搜尋會將一些資訊洩露給伺服器，哪些密文單元可能對應於相同的明文單元。
沒有證據表明 CipherCloud 使用了諧音詞替換密碼。我只提到了這個方案，因為它是對上述方案的最簡單更改，與他們 DMCA 通知中的聲明不矛盾。由於“正在申請專利的機制”，Ciphercloud 聲稱不會受到上述弱點的影響。我當然希望他們的機制比簡單地切換到諧音詞替換密碼更好。
CipherCloud 在其 DMCA 通知中的聲明：
作為這種分析的對立面，這裡有一些在他們的 DMCA 通知中提出的聲明：
此類虛假、誤導性和誹謗性陳述包括以下範例：
(2) “如果相同的字元串在不同的地方被加密，攻擊者可以看到在兩個地方都使用了相同的字元串。”
$$ statement from an old version of this post $$
* 同樣，CipherCloud 的產品不是確定性的。 (4) “正如 CodesInChaos 在之前的回答中所建議的那樣，這使得該解決方案極易受到頻率分析攻擊。”
$$ from AdrenaLion’s post $$
* 引用的方案不代表 CipherCloud 功能。事實上，CipherCloud 擁有正在申請專利的機制來抵禦頻率分析攻擊。 (7) “基本上，它們以小寫單詞的 1:1 映射結束。”
$$ Sid’s post, referring to the message board discussed in this post $$
* 該聲明顯然是錯誤的。Sid 暗示從公開展示中看到的是 CiperCloud 的產品。 $$ emphasis mine $$CipherCloud 不包含 1:1 映射。
（DMCA 通知中包含 10 個範例語句，我選擇了與這篇文章最相關的那些。我插入了將引用的語句連結到其原始文章的註釋）
結論
觀察到的加密具有顯著的弱點，其中大多數是一種方案所固有的，該方案希望加密數據，同時使原始應用程序能夠在不更改該應用程序的情況下對加密數據執行搜尋和排序等操作。可能有一些先進的技術（同態加密等）可以避免這些弱點，但至少影片中展示的軟體沒有使用它們。
我認為將他們的 DMCA 通知中的陳述與觀察到的加密屬性相一致的唯一方法是，實際的 CipherCloud 產品與他們的宣傳材料中顯示的有很大不同（並且更好）。
如果他們不想根據他們發布的關於他們的產品的資訊被評判，也許他們應該更新他們的材料以更接近他們的實際產品。
密碼雲響應
CipherCloud 在他們的部落格上發表了回應：回應關於 CipherCloud 加密技術的神話
很少有具體資訊，但這裡有一些相關部分：
我想澄清一下 CipherCloud 是否使用同態加密的問題。答案是不。由於性能和能力不足，同態加密遠未準備好投入實際使用。
板執行緒中引用的 CipherCloud 產品展示側重於向使用雲應用程序的組織強調我們為雲資訊保護提供的反向代理概念。一些可用的基本安全功能（例如全域加密、通過 IV 隨機化等）被禁用，因為在我們的專利仍在申請中時，我們不願意在網際網路上共享此類 IP。
1實際的亞洲字元與我文章中的不同，但大體形式相同。
2換行符是瀏覽器顯示文本的產物。它可能隱藏了一些字元。