通過改組純文字來減少 AES-CTR 延展性影響

我需要隨機訪問加密和解密文本。為此，我決定在 CTR 模式下使用 AES，這是 CBC 和 GCM 之間的一個很好的折衷方案。

但是CTR模式是有延展性的。這不是一個大問題，因為我將加密的文本沒有預定義模式並且我不需要身份驗證，我只是想避免攻擊者讀取純文字的能力。

但是，我想減少攻擊者真正使用 CTR 的延展性屬性的能力。

這是我的想法：

public static void main() {
   Key key = …;
   IVParameterSpec iv = …;
   int rSeed = …;
   byte[] plainText = …;
  
   AESBlock[] toCipher = cutIntoAESBlock(plainText);

   for (AESBlock aesBlock : toCipher) {
      byte[] shuffled = shuffle(aesBlock, rSeed);
      byte[] encrypted = encryptAES_CTR(shuffled, key, iv);

      …

      byte[] decrypted = decryptAES_CTR(encrypted, key, iv);
      byte[] unShuffled = unShuffle(decrypted, rSeed);
      // Here the content of unShuffled must be equals to aesBlock content.
   }
}

假設方法shuffle(…)和unShuffle(…)是互補的並且一個相反另一個。

洗牌步驟在這裡不是要加密 128 位 AES 塊，而只是洗牌它的位順序**，這樣可以減少攻擊者對密文進行修改的影響，**因為如果攻擊者更改了密文的一部分，**修改將在 unShuffle 階段傳播，**並會改變內容，並減少新內容可被利用的機會。

這樣，CTR 模式始終具有可塑性，但密文修改的影響會降低。

這只是一個想法，我寫這篇文章是為了了解這個想法是否真的有用，或者它是否無用並且只是表面的步驟，它不會減少攻擊者可以對密文進行的修改的影響。

我知道有提供身份驗證的 GCM，因此不可延展。但我真的不需要它，而且 GCM 不能被隨機訪問，特別是如果我想修改和重新加密純文字的一部分。

Kerckhoffs 的原則（或者至少是現代解釋）說我們假設攻擊者知道一般算法，但不知道密鑰。因此，如果攻擊者知道洗牌算法，那麼他們就會知道要在洗牌數據中更改哪些位。最終結果是您獲得了任何安全性。

所以如果你想避免延展性，那麼你將不得不選擇不同的模式。

至於能夠僅讀取/修改部分數據，您可以查看將數據劃分為塊的全盤加密（也值得查看有關 XTS 的這篇文章）。只有完整的塊被讀取和寫入。但請注意，在磁碟上，每次讀/寫通常為 4096 字節（具體值取決於磁碟和作業系統）。因此，無論您打算更改多少數據，從文件讀取、修改數據並將其寫回文件都將涉及讀取/寫入大量數據。加密/解密一個塊所需的時間通常比讀/寫磁碟所需的時間少得多，因此處理整個塊不會大大降低系統速度。

引用自：https://crypto.stackexchange.com/questions/102018