發送帶有密文的 KCV（密鑰校驗值）
我想知道為什麼將密鑰的 KCV 與密文一起發送並不常見。我看到許多系統發送密文並正確地將 IV 添加到例如 CBC 模式加密。將另一個字節與 KCV 一起添加會不會更容易？一個好的分組密碼不應該容易受到已知純文字的攻擊，所以我個人認為發送 KCV 沒有任何問題。
這當然會降低效率，但好處是您可以確定地區分使用錯誤的密鑰和一般的解密失敗。我說“一些”確定性是因為如果第一個
$$ blocksize $$字節（太）亂碼，那麼比較顯然會失敗。也就是說，單個塊、ECB 模式加密$$ blocksize $$字節會以任何方式出錯。 PS cryptoki標準只使用KCV的前三個字節，但我認為這主要是一種方便，只是部分安全措施（反對蠻力）？
我懷疑 KCV 通常不被使用，因為它們的添加不足以值得小額成本。
有許多針對加密方法的密碼攻擊涉及攻擊者修改有效密文，然後讓接收者解密修改後的消息（並觀察接收者如何反應）。由於這些攻擊，通常明智的做法是在消息中包含身份驗證標籤。如果身份驗證標籤未檢出，則接收者拒絕該消息（並且以一種獨立於消息如何修改的方式；這可以防止攻擊者推斷出任何資訊）。
有多種方法可以驗證消息；您可以生成密文的 MAC，可以對明文進行簽名，可以使用加密和驗證的密碼操作模式（例如 GCM）。一種不是有效方法的方法是添加 KCV 值（有效的 KCV 值僅表示 KCV 值是由知道密鑰的人計算的；它沒有說明消息的其餘部分是否被修改） . 因此，如果您使用 KCV，您仍然需要一種身份驗證方法。
這就提出了一個問題：如果您已經包含了一種身份驗證方法，那麼 KCV 會帶來什麼額外的好處？好吧，我看不到太多。如果發送者犯了錯誤，接收者將能夠更早地發現它；但是，這不是我們通常關心的優化（一個可能的例外是密碼密鑰文件加密方法；您可能不想在註意到密碼錯誤之前解密完整的數 GB 文件）。您可能希望嘗試區分發件人使用錯誤密鑰與他犯另一種錯誤的情況；我看不出這通常會有什麼用（請注意，攻擊者將能夠根據他修改密文的方式來模擬這兩種類型的錯誤；因此，如果一種類型的反應對他有用，他可以誘導）。
KCV 不會增加太多費用（另一個密碼塊評估和更多字節的加密成本），但是如果它們沒有帶來任何好處（除了我上面提到的關於文件加密的一個案例，我看不到他們是怎麼做的），很難理解為什麼要支付這麼小的額外費用。