攻擊者可以用這種不安全的 AES-CFB8 用法做什麼？
我相信我在我正在開發的應用程序中發現了 AES-CFB8 的不安全使用，並希望有人能解釋這是不安全的原因和原因，以及攻擊者可以做什麼，例如密鑰恢復，因為這將是該協議的更糟糕的結果.
基本上 AES-CFB8（顯式沒有填充）用於加密數據流，IV/密鑰在伺服器和客戶端流之間重用，IV 與密鑰相同。這是多麼不安全，攻擊是否有可能從中恢復 iv/key。用於 AES 的密鑰是一個共享密鑰，它可能比原始數據包流更容易受到損害，因為具有這種可能的不安全使用的流不那麼敏感，但如果使用的密鑰被洩露，這將是一個更大的問題。
public static SecretKey generateSharedSecret() { final KeyGenerator gen = KeyGenerator.getInstance("AES"); gen.init(128); // AES-128 return gen.generateKey(); }// Decided by client and sent in a secure way to server via RSA and validated via a trusted source. final SecretKey sharedSecret = generateSharedSecret();// This is done on both the server and client after the server has received the shared secret. final Cipher aesCFBEncrypt = Cipher.getInstance("AES/CFB8/NoPadding"); aesCFBEncrypt.init(Cipher.ENCRYPT_MODE, sharedSecret, new IvParameterSpec(sharedSecret.getEncoded())); final Cipher aesCFBDecrypt = Cipher.getInstance("AES/CFB8/NoPadding"); aesCFBDecrypt.init(Cipher.DECRYPT_MODE, sharedSecret, new IvParameterSpec(sharedSecret.getEncoded())); this.enableStreamEncryption(aesCFBEncrypt, aesCFBDecrypt);我環顧四周尋找類似的問題，但沒有一個符合我感興趣的標準，即在客戶端和伺服器上使用密碼作為具有不同實例的 RX/TX 流以及使用密鑰作為 iv 而沒有不同伺服器和客戶端的密鑰。
如果密鑰和 IV 相同，則在與第一個字節進行異或的塊加密之後的第一個中間值在兩個加密操作之間也是相同的。這意味著如果明文的第一個字節相同，那麼這將導緻密文相同，從而將資訊洩露給可能的攻擊者。
當然，這個密文也會傳播到目前保存IV的移位寄存器中。IV 的一個字節被移出到左邊（MSB），密文字節被放置在右邊（LSB）。所以現在下一次加密將再次產生相同的中間值。這意味著下一個相同的明文字節也會直接洩漏數據，以此類推。當然，如果你有很多消息，那麼你可以做很多對，所以數據洩露的可能性更大。
只有當消息之間的明文字節不同時，傳播才會停止。然而，這些最後的字節本身就形成了問題。不同的明文已與相同的中間值進行異或運算以創建密文字節。這意味著密文字節的異或會導致明文字節的異或。這很可能會直接洩露數據，同樣，知道的密文字節越多，可以進行的組合就越多。
好的一面是：IV 儲存在移位寄存器中。由於它僅用作分組密碼的輸入，因此 IV 的值和密鑰可能受到相對較好的保護。
如果低級側通道攻擊是可能的，那麼在移位操作期間可能會辨識一些關鍵位，但在提取任何 IV / 關鍵數據之前，您可能需要進行大量操作。因為在我認為應該考慮它之前，我對旁道攻擊感到驚訝。
您不僅不應該將密鑰數據用作 IV（在 IV 上使用散列會更好），而且您也不應該將密鑰用於不同目的。
由於這些加密不良做法，我會對您所描述的協議的安全性持懷疑態度 - 儘管使用 CFB-8 模式可能已經足以表明協議的設計者不知道他們在做什麼。