使用校驗和而不是雜湊來驗證密碼
讓我們假設在特定情況下我們不能使用像 GCM 這樣的經過身份驗證的加密……
如果我們要使用 CTR，您會如何看待在明文上使用校驗和然後加密整個文本。
我不想使用散列的原因是校驗和已經存在於明文協議中，我不想使用標準認證密碼的原因是因為額外的散列大小，即使它只有 16字節。
提前致謝。
如果我們要使用 CTR，您會如何看待在純文字上使用校驗和然後加密整體。
這是一個非常糟糕的主意（從安全形度來看）。
原因如下：
- 根據您的校驗和，消息的真實性會立即受到明顯的攻擊。例如，如果您的校驗和是 CRC，那麼它是線性的。這意味著攻擊者可以只計算一些 $ \Delta $ 他想插入消息併計算 $ \operatorname{CRC}(\Delta) $ 他可以將它異或到您的消息中，它將被接受為有效消息，因為 $ \operatorname{CRC}(P)\oplus\operatorname{CRC}(\Delta)=\operatorname{CRC}(P\oplus \Delta) $ . 已知這種攻擊適用於WEP。
- **校驗和不如雜湊“硬化”。**校驗和甚至不想成為加密雜湊，也不想抵抗有針對性的攻擊。因此，它們可能會暴露線性行為（見上文）或其他可能允許偽造的弱點。另請參閱“校驗和本質上是加密雜湊的非安全版本嗎？” 在這個問題上。
- **Hash-then-Encrypt 作為組合是個壞主意。**正如您在上面已經看到的那樣，如果您的“雜湊”是線性的，那麼 Hash-then-Encrypt 可能很容易受到攻擊。然而，即使它是非線性的並且攻擊者可以很好地猜測消息的內容，他仍然可以計算 $ H(\text{oldMessage})\oplus H(\text{newMessage}) $ 並將其異或到您的密鑰流中（以及 $ \text{oldMessage}\oplus \text{newMessage} $ ) 並且他輕鬆實現了消息偽造。另請參閱“為什麼 plain-hash-then-encrypt 不是安全 MAC？” 在這個問題上。
- **也非常不鼓勵進行身份驗證然後加密。**即使您的“雜湊”是一個實際的 MAC，首先在消息上使用它然後對結果進行加密也是不可取的。有通用的安全證明可以確保 Encrypt-Then-MAC 是安全的，並且不為 MAC-Then-Encrypt 提供相同的保證，因此不鼓勵使用後者。另請參閱 Lindell 教授對“我們應該 MAC-then-encrypt 還是 encrypt-then-MAC?”問題的回答。.
好的，正如評論中所要求的，讓我們深入了解我在第一個要點中概述的攻擊。
讓我們稱密文 $ C $ ，（未知）消息 $ P $ 和（未知的）密鑰流 $ K $ ，由 CTR 模式內部使用。當您使用流密碼時 $ C=M\oplus K $ （和 $ \oplus $ 表示按位異或）是加密函式。請注意，對於所有選擇 $ A $ 和 $ B $ 你可以想出一個 $ C $ 這樣 $ A=B\oplus C $ . 現在在第一步中，我們操作消息 $ M $ . 所以我們首先計算解密後我們希望看到的差異，我們稱之為 $ \delta $ . 現在我們攔截 $ C $ 並且寄出 $ C’=C\oplus \delta $ 向前。注意如何 $ C’\oplus K=M\oplus\delta $ 將在解密時產生被操縱的消息。所以現在我們分開 $ M $ 進入明文的串聯 $ P $ 及其校驗和 $ \operatorname{CRC}(P) $ 作為 $ P\parallel\operatorname{CRC}(P) $ . 現在也分 $ \delta=\Delta\parallel\operatorname{CRC}(\Delta) $ . 現在你看到你會得到 $ P\oplus\Delta $ 在解密為明文和 $ \operatorname{CRC}(P)\oplus\operatorname{CRC}(\Delta) $ 作為校驗和。現在因為 CRC 是線性的 $ \operatorname{CRC}(P)\oplus\operatorname{CRC}(\Delta)=\operatorname{CRC}(P\oplus\Delta) $ 這是偽造消息的有效校驗和。