FIPS 202/SHAKE：不安全的 3DES 密鑰派生範例
我試圖理解FIPS 202（SHA-3 標準）的以下段落，討論不同輸出長度的 SHAKE 函式的相關輸出以及它們在某些協議中引起的風險。他們給出的例子是這樣的（附錄 A.2，“可擴展輸出函式的附加考慮”，第 25 頁）：
$$ A $$兩方同意從指定為 $ keymaterial $ 將是計算 $ SHAKE128(keymaterial, keylength) $ ， 在哪裡 $ keylength $ 是 112。但是，如果攻擊者能夠誘使其中一方使用不同的值 $ keylength $ ，比如 168 位，但相同的值 $ keymaterial $ ，那麼雙方最終將得到以下密鑰：
- $ SHAKE128(keymaterial, 112) = \mathbf{fg} $
- $ SHAKE128(keymaterial, 168) = \mathbf{fgh} $ ,
其中，摘要的粗體字母代表 56 位字元串，例如，三重 DES 密鑰的部分。
由於 Triple DES 的結構，這些密鑰很容易受到攻擊。
我試圖更具體地理解這個例子。到目前為止，我能弄清楚的是這種情況：
愛麗絲和鮑勃建立了一個共享秘密 $ keymaterial $ , 現在應該同時計算 $ SHAKE128(keymaterial, 112) = fg $ , 並用密鑰實例化 3DES $ f, g, f $ .
然而，夏娃欺騙愛麗絲進行計算 $ SHAKE128(keymaterial, 168) $ . 所以現在：
- Alice的加密函式是 $ E^{3DES}_{f, g, h} = E^{DES}_f \circ D^{DES}_g \circ E^{DES}_h $ ;
- Bob的解密函式是 $ D^{3DES}_{f, g, f} = D^{DES}_f \circ E^{DES}_g \circ D^{DES}_f $ .
Alice 的加密函式和 Bob 的解密函式的組成是 $ D^{3DES}{f, g, f} \circ E^{3DES}{f, g, h} = (D^{DES}_f \circ E^{DES}_g \circ D^{DES}_f) \circ (E^{DES}_f \circ D^{DES}_g \circ E^{DES}_h) $ .
簡化該方程中的相鄰逆，我們得到 $ D^{3DES}{f, g, f} \circ E^{3DES}{f, g, h} = D^{DES}_f \circ E^{DES}_h $ .
此功能容易受到中間相遇攻擊。
如果我在這裡完全走在正確的軌道上，我會卡住的地方是：什麼更大的場景可以讓夏娃利用這一點？我可以想像這個場景：
夏娃有這些權力：
- 誘使 Alice 和 Bob 錯誤地獲取他們所描述的 3DES 密鑰；
- 為 Alice 選擇消息以加密並觀察 Bob 對它們的解密。
Eve 使用這些來發起中間相遇攻擊，從而恢復 $ f $ 和 $ h $ 在 $ 2^{57} $ 時間。
所以現在夏娃知道了 $ SHAKE128(keymaterial, 168) = fgh $ 對於一些未知的 $ g \in {0, 1}^{56} $ . 這當然允許 Eve 蠻力 $ g $ 在額外的 $ 2^{56} $ 嘗試，但如果 $ SHAKE128 $ 具有抗原像性，Eve 應該仍然難以恢復 $ keymaterial $ . 那些危險的場景也是如此 $ keymaterial $ 是一個長期密鑰，因此 Alice 和 Bob 將使用相同的派生密鑰進行多次通信 $ f $ 和 $ g $ ?
（我擔心這可能是一個是/否的問題，但我認為我上面一定有什麼問題……）
在某些情況下，夏娃不必欺騙任何人。在 FIPS 202 的場景中，各方嚴重使用了 XOF，因此錯誤不一定是由 Eve 觸發的。
您問題中的方程式確實不需要。我的猜測是你讓它變得比它需要的更複雜。
假設 Alice 和 Bob 使用 3DES 和 2 個密鑰 $ f $ 和 $ g $ 那麼攻擊這個雙鍵 3DES 密鑰意味著克服約 80 位的安全強度（假設選擇的對 2 鍵 3DES 的明文攻擊是可能的，但是嘿，我們不排除這裡的任何攻擊）。
一次鍵 $ f $ 和 $ g $ 知道關鍵 $ h $ 可以簡單地強制使用，因為單個 DES 只有 56 位的強度 - DES 本身的強度。但是，這意味著最大操作數 $ 2^{80} + 2^{56} $ ， 不是 $ 2^{80} \times 2^{56} $ . 換句話說，最終方案的強度約為 80 位，而不是三密鑰 3DES 所承諾的 112 位。刪除 32 位安全當然算作任何方案的中斷。
您寫下的最終結論：這主要是長期（或至少經常使用）密鑰的問題，這似乎是正確的。
FIPS 文件試圖說明的一點是，即使輸出大小不同，您也不應該重用XOF 的輸出 - 例如，當用作密鑰派生函式 (KDF) 的基礎函式時。
這確實與 XOF 本身的安全性無關。