这些是Mcrypt中的标准实现。我隐约意识到，更大的块大小可以帮助减轻某些类型的攻击……是真的吗？哪个？更大的块大小还会引入弱点吗？我只是想知道为什么128位版本成为标准，以及是否有充分的理由使用256位版本。
#1 楼
我很好奇，为什么128位版本成为标准[。]
这个问题很容易回答。在AES的候选算法提名请求的最低可接受要求部分中，它说：
候选算法应能够支持大小为128-128的密钥块组合， 192-128和256-128位。提交的算法可能支持其他关键块大小和组合，并且在分析和评估时将考虑这些功能。
因此，支持不同的块大小被认为是理想的属性。 ，甚至在比赛开始之前就已经确定了AES的块大小，即，它与Rijndael算法本身无关。
我隐约知道更大的块大小可以帮助减轻某种攻击...是真的吗？
对于某些攻击，是的。
某些操作块模式（例如CBC）要求相同的密文永远不会生成两次。如果$$ E（C_1 \ oplus P_1）= E（C_2 \ oplus P_2）$$（$ P_i $表示明文块，$ C_i $表示前一个密文，$ E $表示加密函数），因为$ E $是双射的，$$ C_1 \ oplus P_1 = C_2 \ oplus P_2，$$，因此，$$ P_2 =（C_1 \ oplus C_2）\ oplus P_1。$$
因为$（C_1 \ oplus C_2 ）$是设计已知的，如果您也知道$ P_1 $，则可以派生$ P_2 $（请参阅：代码本攻击）。
块大小为$ n $位，冲突就变成了大概在$ 2 ^ \ frac n2 $块明文之后（请参阅：生日问题）。这是DES的问题（块大小为64位，$ 2 ^ {32} $块仅为32 GiB纯文本）。在可预见的将来，128位的块大小（$ 2 ^ {64} $块为256 EiB纯文本）就足够了。
同样的问题也适用于其他阻止操作模式（例如CTR），尽管发动成功的攻击并不容易。在大约$ 2 ^ \ frac n2 $块之后，应该开始发生冲突。但是在CTR模式下，$ E（nonce + counter）$不会在前$ 2 ^ n $块中产生任何冲突。因此，在给定的点上，流将变得与随机流区分开（请参阅区别攻击）。
更大的块大小还会引入弱点吗？
总的来说，是的。
尽管XTEA简单，但它仍然保持不变。但是，其扩展的Block TEA（XTEA是具有64位块大小的Block TEA）易受差分密码分析的影响（请参阅：微小加密算法的密码分析）。
I我只是好奇[...]是否有充分的理由使用256位版本。
绝对不行！
在AES提案中：Rijndael ，作者说：
对于具有更大块长度的Rijndael版本，对于块长度的每增加32位，对于
，轮数增加1。原因如下：
对于128位以上的块长度，需要3轮才能实现完全扩散，即，相对于块长度的一轮扩散能力，
较大的块长度会导致可应用在一系列回合序列的输入/输出上的可能模式的范围增加。这种增加的灵活性可以允许将攻击扩展一轮或多轮。
此外，作者建议使用$ Nr = max的一轮（$ Nr $） （Nk，Nb）+ 6，$$，其中$ Nk $是密钥大小，$ Nb $块大小（均在32位块中）。
这意味着Rijndael-128-256将比Rijndael-128-128（AES-128）慢，并且Rijndael-256-256的安全裕度可能低于Rijndael-256-128。
底线
Rijndael N-256几乎没有像AES那样受到关注，因此它可能有一些未发现的弱点。
相比之下，AES被认为是安全的，尽管比其他任何加密算法都要进行更多的密码分析。 。
128位块大小不是问题。如果没有损坏，请不要修复！
评论
$ \ begingroup $
至少这不是加密问题。如果要从AES构建哈希函数（从理论上讲-在现实生活中您不这样做，而是使用为此目的设计的原语），则需要选择高速率压缩函数以补偿较小的块大小。
$ \ endgroup $
–托马斯
13年1月18日在5:20
$ \ begingroup $
大多数加密模式都没什么大问题。但是您可能会争辩说，在点击率方面（因此在基于点击率的其他模式下），这是非常小的：对于随机随机数，如果增加随机数的大小，则64位就不会那么多而不是要包含在密文中的$ 2 ^ {64} $个块。随机数为128，计数器为128，您完全不必担心。
$ \ endgroup $
–马腾·博德威斯♦
17-2-2在13:18
$ \ begingroup $
“ Realise”并不是美国英语，但在大多数英语国家中仍然是正确的拼写。这不是错字。
$ \ endgroup $
–森林
18年5月2日在3:18