使用單向雜湊函式作為加密方法
假設兩方（Bob 和 Alice）想要使用一個簡單的英語消息系統進行安全通信。英語中目前使用的單詞大約有180,000個。
協議
- Bob 創建一個長度為 512 位的隨機私鑰，例如
2fba5541fda58c643524cb629cb310674d029d7dd688e974f9c0d95299c228fa3531d06a29a69b6715ad4ec074d2bb50393fe5b4e7d2de5bc83b10ac7d3114ff- Bob 還從一組都輸出 512 位的散列函式中選擇一個隨機散列函式。這些可能是 SHA-2、Keccak、Grøstl、BLAKE、JH、Whirlpool 和 Skein 雜湊函式。
- Bob 將密鑰和選擇的散列方法提供給 Alice（親自或使用其他密鑰交換方法）。
- 使用一個程序和 180,000 個單詞的字典，Bob 和 Alice 使用選擇的散列函式計算字典中每個單詞的 HMAC(key, word)。每個人都在他們的機器上計算這個。
- 這些值儲存在每個人機器上的索引數據庫中的帶有列（id、word、hmac）的查找表中。在單核上每個字的 HMAC 生成時間為 23 毫秒（參考機器：Core i5 @2.67GHz），這將需要 69 分鐘來建構一個包含 180,000 個字的值的數據庫。使用所有 4 個核心，拆分工作並使用多執行緒程式，這可以減少到 17 分鐘，以在每台機器上生成完整的數據庫。這是一次性的一代，所以沒什麼大不了的。
- Bob 給 Alice 寫消息。
- 對於加密，程序選擇消息中的每個明文單詞，然後在數據庫中查找相應的 HMAC 雜湊值，然後用該雜湊值替換明文單詞。在現代索引數據庫中，對每個單詞和相應雜湊的數據庫查找將非常快。
- 每個單詞的雜湊值連接在一起，因此它是一整串難以理解的文本。這構成了密文。
- 使用 HMAC(key, ciphertext) 在文本上計算消息驗證碼，並與消息一起發送，例如密文 || MAC（串聯）。
- Alice 收到加密的消息。獲取消息的最後 512 位，即 MAC。然後使用她的密鑰副本和使用 HMAC（密鑰，密文）的雜湊算法驗證 MAC。不正確的 MAC 意味著消息會立即被丟棄。
- Alice 的程序將消息分解成散列的單詞，因為它知道每個單詞都被散列成一個固定長度的 512 位散列。
- Alice 的程序在她的數據庫的詞詞典中查找每個散列詞，以檢索相應的明文詞。該程序為她將消息組裝回明文。在現代索引數據庫中，每個單詞和相應雜湊的數據庫查找也應該非常快。
安全功能：
- 該協議的強度取決於計算其中一個散列詞的 HMAC 散列的原像以找到密鑰的難度。對於使用蠻力搜尋的標準電腦，這將是 2 512或使用 Grover 算法的2 256 。
- 還有一個安全性是攻擊者不知道任何一方使用了哪個散列函式。他們將不得不嘗試使用所有可用的 512 位雜湊算法進行暴力破解。
- 所有散列字計算到相同長度的輸出，例如 512 位。這意味著較短的單詞與較長的單詞無法區分。
- 如果散列輸出和 MAC 連接為單個字元串並發送，則輸出與隨機字元串無法區分。
潛在的缺點：
- 如果該詞重複並發送多次，則輸出的頻率分析可能有助於確定密文中的簡單詞，例如“the”等。這不一定是一個問題，因為它只是一個簡單的詞，並沒有傳達太多的資訊含義。您也可以通過在消息中完全不使用簡單的單詞來避免這種情況。
- 該消息不考慮數字或標點符號。解決方案是發送簡單的消息，例如“LEAVE MIDNIGHT”，然後可以在另一條消息中發送任何進一步的句子。數字也可以擴展到它們的等價詞，例如“2”變成“TWO”。
- 生成單詞/雜湊字典的時間可能很耗時。如前所述，使用快速電腦和多執行緒程序在每台電腦上創建字典可能只需要 17 分鐘。使用 Core i7 或不斷提高的電腦速度，它會更快。從那裡可以將相同的字典傳輸到需要通信的任何其他設備。
- 加密的輸出比消息本身長得多。考慮到當今的網路和儲存能力，這並不是什麼大不了的事。
- 假設攻擊者知道該協議，他們可能能夠根據密文的長度來辨別消息中有多少單詞。這可以通過使用填充詞和設置固定長度的消息大小來解決。
回饋
現在我會很感激一些建設性的回饋。
- 目前有沒有類似的加密系統在使用？
- 協議還有什麼問題？
- 還有哪些缺點和緩解措施？
- 有哪些可以改進的地方？
回饋後更新
在對該方案進行回饋後，它很容易受到選擇明文攻擊和過去消息的頻率分析，除非每個單詞只使用一次。這不是特別有用，所以我設計了一些更改。
為每條消息創建一個隨機 nonce/IV。這將是 512 位並與消息一起發送。為了加密，Bob 為消息中的每個單詞計算 HMAC(key, nonce || word)。|| 表示串聯。加密將非常快，並且不再需要查找字典，因為它會更改每條消息。
對於解密，Alice 使用 HMAC(key, nonce || word) 為字典中的每個單詞構造一個臨時字典。Alice 的程序在她的數據庫的詞詞典中查找每個散列詞，以檢索相應的明文詞。然後程序重新組合明文消息。
唯一的缺點是每條消息的解密會比較慢。這可以通過使用更強大的硬體（例如更快、更現代的 CPU 或多 CPU/多核伺服器系統）並為每個核心拆分工作來加快速度。更強大的硬體會減少解密時間。該方案仍然保持安全性，因為攻擊者很難 (2 512 ) 找到原像並檢索原始密鑰，尤其是當他們不知道正在使用的確切雜湊算法時。這對於擁有用於發送和接收消息的專用硬體的組織來說是理想的選擇。
對於目前的現代 PC，可能可以減少散列算法的輸出大小，例如 256 位，以減少每條消息的解密時間，同時仍保持良好的安全裕度。量子密碼學可以將其減少到2128來找到一個原像，但是即使對於擁有超級電腦的攻擊者來說，這仍然是很長的時間。我不會將雜湊大小降低到該值以下。
您的方案將為業餘密碼破解者提供一個很好的難題。這是可以說的最好的了。
它不符合現代加密方案的普遍接受標準；特別是，它在語義上並不安全。事實上，即使攻擊者獲得了少量的已知明文，您的方案的安全性也會受到嚴重損害，並且如果用於加密足夠數量的文本，它甚至可能容易受到使用頻率和相關性分析的純密文攻擊.
特別要注意，您聲稱的“安全特性”之一不成立：如果明文包含任何重複的單詞，則可以通過重複的 512 位塊（其中，在真正隨機的字元串，在天文上是不可能的）。
也就是說，如果您真的想要一個使用 HMAC 的安全逐字加密方案，這裡有一個可行的方案變體：
- Bob 和 Alice 選擇一個 512 位的散列函式。這個選擇可以是公開的，所以讓我們選擇SHA-512並完成它。
- Bob 和 Alice 以某種方式安排共享密鑰K 1。密鑰可以是任意大小，只要它的長度足以抵抗暴力猜測嘗試即可；128位或更多應該沒問題。
Bob 和 Alice 也都以某種約定的方式修改K 1以獲得第二個共享密鑰K 2 ≠ K 1。修改可以完全是微不足道的，例如翻轉密鑰中的第一位；我們只需要兩個不同的鍵；原因見下文。（但是，出於技術原因，應避免附加空字節或散列K 1以獲得K 2。幾乎任何其他方法都可以。）
- 為了向 Alice 發送消息，Bob 將消息拆分為單詞（每個單詞不超過 64 個字節 = 512 位）。
可選地，Bob 還選擇一個“nonce”單詞或片語並將其附加到消息中。這個nonce 詞可以是隨機的，或者它可以只是例如一個消息號。Bob 在消息中包含時間戳和通道指示符（例如“從 Bob 到 Alice”）也是一個好主意，以防止重放攻擊；如果是唯一的，這些可以用作隨機數。
首先，Bob 使用選擇的散列函式和共享密鑰K 1計算整個消息的 HMAC（就像 Alice 解密時的樣子，包括隨機數，如果有的話）。這將形成密文的前 64 個字節。
為了加密消息的每個單詞，Bob 使用密鑰K 2計算密文的前 64 個字節的 HMAC，將要加密的單詞與 HMAC 輸出（例如用空值填充到 64 個字節）進行異或，並附加結果密文的 64 字節字元串。
- 為了解密消息的第一個字，Alice 獲取密文的前 64 個字節，計算它們的 HMAC（使用密鑰K 2）並將結果與密文的下 64 個字節進行異或運算。然後，她對所有後續的 64 字節塊對重複該過程，以解密消息的其餘部分。
最後，Alice 使用密鑰K 1計算整個解密消息的 HMAC，並將其與密文的前 64 個字節進行比較。如果它們匹配，她就會知道消息來自 Bob（或其他知道密鑰的人）並且沒有被篡改。
與您的方案相比，此方案具有許多優點：
- 它不需要數據庫。
- 它可以處理任意單詞（除了 64 字節長度限制，這在實踐中不應該成為問題），即使它們在任何字典中都找不到。
- 它還可以處理標點符號，例如將其視為單獨的單詞，或將其附加到前面的單詞中。
- 如果每條消息都包含一個唯一的隨機數，則它是IND-CCA2安全的，即它滿足現代加密方案的最高安全要求。
- 即使不使用隨機數（或意外重用），IND-CCA2 的安全性也會受到損害，即攻擊者可能會知道同一消息是否被發送兩次。
附言。細心的讀者可能會注意到，Bob 將消息拆分為“單詞”以對其進行加密的要求有些多餘：Bob 將其消息拆分為 64 字節塊會容易得多。
這也使 Bob 不必擔心將塊填充到 64 字節，可能除了最後一個塊。對於最後一個塊，Bob 可以（如果他不介意洩露明文的確切長度）只是將 HMAC 輸出截斷為最後一個明文塊的長度，而不是填充明文。
通過這些修改，我上面描述的方案本質上是SIV 模式的簡化版本，除了基於 HMAC 和 CFB 模式而不是 CMAC 和 CTR 模式，並且使用 HMAC 作為分組密碼的替代品進行加密。所有這些修改都應該是安全的，儘管它們嚴重依賴 HMAC 的安全屬性（特別是 HMAC-SHA512 是PRF）。SIV 模式的好處在於它“最大程度地防止誤用”。無論您做什麼，都很難使其安全性發生災難性故障。
**更正：**我最初建議的協議如果在沒有隨機數的情況下使用，它將很容易受到嚴重的選擇明文攻擊：如果 Eve 可以欺騙 Alice 或 Bob 加密她選擇的消息，她可以送出任何 64 字節塊從較早的密文作為消息，以學習其HMAC，從而學習較早消息中的相應單詞。我已經修改了協議以使用不同的 HMAC 密鑰進行身份驗證和加密部分，這應該可以堵住這個漏洞。故事的寓意是，要小心密鑰重用！