Block-Cipher
塊密碼中非常大的塊大小有什麼缺點？
假設有人創建了一個塊大小為 8192 字節（65536 位）或塊大小為 16384 字節（131072 位）的塊密碼。
與具有較小塊大小（如 128 或 256 位）的塊密碼相比，它有什麼缺點？
- 填充問題：如果使用像 CBC 這樣的分組密碼模式，那麼他們需要填充，並記住無論大小如何，總是應用填充。即使大小 $ 65536*k $ 然後需要一個新的完整塊。不清楚如何應用 PKCS#7 填充，因為它支持多達 256 字節的塊。還有其他簡單的填充可以應用，例如添加
1零然後編碼填充大小。在現代密碼學中，我們遠離填充模式，我們正在使用像 AES-GCM 和 ChaCha20-Poly1305 模式這樣的模式，這些模式是無墊認證的加密模式。
- **輪數：**如果我們考慮每 32 個塊需要額外一輪的 Rijndael，類似的塊密碼將需要 2048 輪才能達到相同的安全級別（請記住，這確實是一個粗略的估計）。這會為第一個輸出創建延遲。比 AES-256 的第一個輸出慢約 148 倍。雖然這種延遲對於 Signal 上的消息傳遞可能並不重要，但在某些地方延遲並不可取。
- **密鑰大小問題：**在 SPN 中，我們使用密鑰來 x 或舍入值。如果密鑰大小小於塊大小，這確實是一個安全問題，可能會導致線性和差分攻擊新的可能性。因此，需要生成、交換傳輸和儲存大小為 65536 位的密鑰。
- **實現問題：**撇開軟體上的恆定時間實現不談，在硬體上這樣的規模將需要更多的面積來實現。這將增加實施成本，並且需要比較小尺寸的分組密碼更多的功率。
- **消息大小問題：**對於比塊大小更短的消息，這在數據庫中很常見，如果使用 CBC 模式，這將產生大小問題。是的，使用基於 CTR 的模式可以緩解這種情況，但是，與較短的塊大小的密碼相比，加密/解密將花費更多時間。
- **後量子：**這在後量子上沒有優勢，因為 AES-256 已經對 Grover 的最優算法安全。
- 我們是否需要大於 128 位的分組密碼？
是的。例如，如果 AES 完全按照 Rijndael 進行標準化，那麼 AES-GCM 的隨機 nonce 問題對我們來說將不再是問題。大小為 256 的隨機 nonces 在同一個密鑰下是安全的。
- 我們有大於 256 位的分組密碼嗎？
是的，在 CTR 模式下具有 512 位輸出的 CPU 友好型 ChaCha20。使用 XChaCha20，它具有 192 位隨機數大小，可以很好地防禦隨機數衝突。