為什麼迭代置換-置換積密碼只用於固定大小的明文塊？
問這個問題的另一種方式是：在發明分組密碼時，為什麼要添加分組密碼僅限於固定大小的塊的限制？
從我外行的角度來看，我不明白為什麼不能使用可變大小的輸入執行輪次的 S-box 和 P-box 操作。
讓我們從什麼是分組密碼開始；
分組密碼是一系列排列$$ F:{0,1}^\ell\times{0,1}^b \to{0,1}^b $$在哪裡 $ \ell $ 是關鍵長度和 $ b $ 是塊大小（DES 有 64，AES 有 128 位塊大小）。從關鍵空間 $ \mathcal{K} $ 和 $ 2^\ell $ -size，具有給定的分組密碼 $ k \in \mathcal{K} $ 從所有可能的排列中選擇一種排列 $ {0,1}^b \to{0,1}^b $ . 這最多使 $ 2^b! $ 排列。使用斯特林公式
$$ 2^{b}! \approx \sqrt{2\pi 2^{b}} \bigl(2^{b}/e\bigr)^{2^{b}} $$如果你插入一些像 AES-256 這樣的數字，你會看到密鑰空間與可能的排列數量相比有多小；
$$ 2^{256}! \approx \sqrt{2\pi 2^{126}} \bigl(2^{256}/e\bigr)^{2^{256}} != \sqrt{2\pi 2^{256}} e^{-2^{256}} \bigl(2^{256}\bigr)^{2^{256}} \gg 2^{256} $$
我們仍然希望像 AES 這樣的分組密碼是偽隨機排列 (PRP)，無法與隨機排列區分開來。20 多年來，沒有人能夠證明 AES 的區別，也沒有人能夠證明這一點。我們堅信這是一個 PRP。
為什麼迭代置換-置換積密碼只用於固定大小的明文塊？
替換（AES 中的 Sbox）可用於設計更大的塊大小，但是，當您將塊大小從 64 位更改為 128 位時，您需要一個新的排列。此外，為了獲得更好的設計，您還需要更改替換。
當塊大小越來越多時，擴散的控制（AES 中的 MixColumns+ShiftRows）也會變得更加困難。
以上是這種設計的一些理論方面。軟體和硬體還有其他問題。您需要為軟體和硬體實現許多不同的大小。這將增加成本和麵積。此外，在硬體方面，我們希望小設計以減小面積和降低功耗。即使使用 CTR 模式也會刪除分組密碼的解密實現。
儘管人們可能很容易在軟體中實現這些，但問題卻成倍增加。您需要為每個實施提供針對側通道攻擊的對策。這同樣適用於硬體。然而，我們並非完全能夠做到這一點，我們將面臨多個問題。請參閱 AES 側通道攻擊，包括 AES 上的記憶體攻擊。
相反，最好設計一個具有固定塊大小的塊，以便我們可以更集中地對其進行分析。有一篇關於分組密碼分析方法的好文章；
當然，我們可以使用具有各種操作模式的分組密碼來實現對大消息進行加密的目標。這裡就不一一列舉了，各有利弊。有的要提
CBC 模式是一種基於鏈的模式，它使用填充來實現對長消息的加密。您需要小心隨機選擇密鑰統一，選擇不可預測的 IV，並儘可能應用 HMAC 來針對位翻轉攻擊和填充預言攻擊進行身份驗證。
CTR 模式是一種基於計數器的模式，它將分組密碼轉換為流密碼，請在此處閱讀，而不是列出所有優缺點；AES-CTR 的缺點？. 在您的情況下，CTR 模式根本不需要填充，可以加密任意長的消息（不是那麼長，為 PRF 設計的 CTR 在使用 PRP 時要小心）。
使用上述模式，您只能實現 CPA 安全性，而在現代密碼學中，我們需要的不止這些。應該使用經過身份驗證的加密模式 (AE)（並且可能使用關聯數據 (AEAD)），例如 AES-GCM 和 ChaCha20-Poly1305。您將獲得比 CCA (AEAD > CCA) 更多的成就。各有優劣，
這兩種模式的一個真正問題是（密鑰，IV）對的重用。兩種模式都有擴展；
如果塊大小小於 128，任意塊大小也會有問題。有一個不錯的頁面，請參閱
您的情況的另一種解決方案是流密碼，它們旨在快速並且可以加密大塊大小。它們不需要填充，並且在某些設計中它們是逐位或更多的加密。
問這個問題的另一種方式是：在發明分組密碼時，為什麼要添加分組密碼僅限於固定大小的塊的限制？
上述原因，尤其是設計和實現。如果你考慮到在那個時代，人們沒有像今天這樣進步，這一點就會更加清楚。時間表明，有些決定是正確的。
從我外行的角度來看，我不明白為什麼不能使用可變大小的輸入執行輪次的 S-box 和 P-box 操作。
堅持，稍等！它們不是像 LEGO 中那樣的神奇工具，您可以用 4 個 2x2 積木代替 2x8 積木。即使在某些地方，結構也會失效！
設計中的每個變體都需要進行設計、分析，並且需要良好的實施。