在實際使用之前檢查密鑰
我有一個使用 128 位密鑰的 twofish 加密的數據塊。
必須從 GUI 訪問數據，使用者給出密鑰，解碼塊並訪問真實數據。
問題是我需要在嘗試解碼塊之前確保密鑰是正確的。
我目前的解決方案是有一個文件（比如
chk.blk），它是一些數據的加密，我可以用它來測試密鑰的正確性。最初我有一個文件
chk.blk是對已知數據（比如 text12345678）的加密，然後我認為這可能會危及密鑰。真的嗎？如果攻擊者同時擁有原始數據和加密數據，twofish 是否有任何弱點？擔心會出現這種情況，我現在生成具有給定屬性的隨機文本（例如
x...x..x，.任何不同於 的字元在哪裡x）。我拿鑰匙，解碼chk.blk並驗證結果是否具有所需的屬性。這個想法是，現在攻擊者沒有一個已知的文本可以使用，而是一個相當大的組。當然，我不能確定密鑰是否真的正確，使用者可能偶然使用了一個生成解碼文本的密鑰，該文本具有完全所需的屬性，但我認為機率極低。 您認為這種方法有什麼問題嗎？有什麼建議嗎？
使用場景
我在此處添加更多資訊以闡明預期用途。
想像一下，您有一組相當大的文件（5Mb 的數據）必鬚髮送給大量收件人（例如 10.000 個）。這些文件必須絕對保密，直到給定的日期/時間（比如 2012 年 12 月 21 日 21:12）。
從現在到那時，所有收件人都可以在他們的 PC 上下載文件以及解密程序。他們將到達指定的目的地，並在那裡等待在適當的時間接收解碼密鑰。
精確同步並不重要，但他們都必須（幾乎）同時閱讀文件。
在給定日期之前，任何人都不能閱讀文件，這是絕對強制性的。
它們將位於可能無法連接到網際網路的地方，這就是他們必須事先下載文件的原因。
然而，他們都將能夠使用密鑰接收消息（例如，通過 SMS、通過電話、通過電影片道或廣播電台廣播， …）。
因此，這個想法是分發加密了 128 位安全性的文件，這應該足以保護密鑰幾個月，然後將密鑰作為字元串（26 個字元）分發。
為了使對稱分組密碼被現代標準認為是安全的，它必須是IND-CPA，這與在選擇的純文字攻擊下的隨機預言無法區分。它還必須是 IND-CCA 和 IND-CCA2，但 IND-CPA 足以讓它在已知的純文字攻擊下也很安全。
假設 TwoFish 仍然完好無損，因此使用單個已知塊的密文作為密鑰驗證器應該是安全的。或者，更準確地說，將該 chk.blk 文件與加密文件一起儲存不會顯著揭示有關密鑰的更多資訊。
但是，您可能已經或可能尚未意識到您的方法存在其他問題。
首先，您真的認為讓使用者使用 GUI 輸入完全隨機的 128 位密鑰是可行的嗎？大多數應用程序在這種情況下使用密碼片語，在這種情況下，您的方法應該略有不同。首先，您將 PBKDF 的鹽存放在哪裡？密鑰會用於加密多個文件嗎？僅通過查看已知使用相同密鑰加密的兩個文件的密文，對手將能夠推斷出哪些資訊？
其次，如果唯一的威脅是對手，您的方法實際上是安全的，沒有訪問密鑰但對驗證者和實際密文具有隻讀訪問權限，試圖猜測與密文對應的純文字內容。您的計劃不足以防止超出該情況的任何事情。
鑑於您的具體問題，我建議在您的有效負載中嵌入一個 MIC。消息完整性程式碼是嵌入在消息中的校驗和，並與消息一起加密。您不必使用安全雜湊，它可以是任何東西。我更喜歡 Fnv1，因為它實現起來很簡單。
校驗塊的問題在於，攻擊者知道校驗消息的內容，校驗消息的大小很小，因此攻擊者可以使用較小的消息作為對較大消息的攻擊的代理。較小的消息需要更少的時間來解密。
使用 MIC，必須使用候選密鑰對消息的全部內容進行解碼，然後計算 MIC。這給攻擊者增加了額外的計算負擔。
你可能已經想到了這一點，這讓我懷疑解密程式碼是否不在你的控制之下。