#1 楼
明文攻击（即知道一对对应的明文和密文）总是允许对密码进行蛮力攻击：它与明文匹配。这始终适用于每个密码，并会为您提供匹配的密钥。 （对于非常短的明文-密文对，您可能会获得多个匹配密钥。然后，您需要尝试更多对以消除错误的密钥对。）
如果没有已知的明文，则仅密文可以类似地执行此操作，但是您还需要一个函数来说明您解密的内容是否是合理的明文。
尝试所有密钥的问题在于，对于每个现代密码（即128位密钥或更多）密钥空间如此之大，您需要比宇宙剩余寿命更长的时间来检查所有密钥的重要部分。
所以，问题是，是否存在任何攻击比暴力破解还要快？
目前看来，有些攻击要稍快一些（例如，暴力破解只需要$ 2 ^ {125} $步而不是$ 2 ^ {127} $ ，对于256位密钥版本来说要好一些），并且需要大量选择的明文或密文（并知道结果），甚至需要更多的已知明文s。在我们的世界中，这些实际上仍然是行不通的。成功”（或者至少没有成功的人告诉公众）。
评论
$ \ begingroup $
“没有人成功” 2013 / nsa更新：“据我们所知...”
$ \ endgroup $
–吕克
13年9月16日在18:54
$ \ begingroup $
我在阅读OP的问题时特别询问了AES为何抗拒明文攻击的原因和方式-该答案并不能真正回答所有问题（我个人不认为暴力攻击为“明文”攻击”）。这个问题可以改写为“ AES的设计如何防止琐碎的尝试从已知的明文派生加密密钥？” -例如，考虑使用Engima / Bletchley Park基于Crib的方法在邮件中找到“Wetterübersicht”。
$ \ endgroup $
–代
19年1月11日，下午3:14
$ \ begingroup $
@Dai如果密钥空间较小，则对所有密钥进行蛮力尝试以查看您的已知明文是否与已知密文实际上匹配，并且比未知明文要好一些（您需要检查解密结果是否有意义）。我不是密码设计专家，所以我无法回答您的问题。
$ \ endgroup $
–PaŭloEbermann
19年1月11日在10:47
#2 楼
好吧，“为什么AES能够抵抗已知明文攻击”的答案是，好吧，很多真正聪明的人都在思考如何破解AES，没有人提出实用的方法，或者假设已知的明文或选择的明文。鉴于当前的知识水平，请参阅将AES花费多少以获取蛮力，以进行讨论。免疫”，答案是，是的，据我们所知。#3 楼
差分密码分析是纯文本攻击的一种形式。维基百科有关差分密码分析的文章说，AES在设计时就考虑到了抵抗这种攻击的能力。维基百科甚至说可以通过数学方法证明这种抵抗力，但不提供这种抵抗力。#4 楼
使用已知明文的经典攻击实质上是向后运行加密并构造密钥。不需要强力，您只需要足够的匹配明文和密文，其中“足够的”长度可以小于密钥长度（对于足够脆弱的密文）。抵抗密码会对密码状态进行内部混合，因此这是不可能的。您想到的第一个加密系统可能是对纯文本与伪随机数生成器的输出进行异或。该加密系统仅具有约64位的隐藏状态，每个加密的字母可显示其中的8个。你明白了。
评论
$ \ begingroup $
您如何计算64位状态，其中8位如何显示？ （此外，我想我在听说XOR或位/字节之前就想到过加密系统。）（顺便说一句，使用加密安全的PRNG是一种安全的加密方式，只要您不重用种子即可。 ）
$ \ endgroup $
–PaŭloEbermann
2011-12-23 22:14
$ \ begingroup $
在Knuth中发现的经典随机数生成器只有几个整数作为其内部状态。
$ \ endgroup $
– ddyer
2011-12-23 23:02
$ \ begingroup $
这说明有关随机数生成器的更多信息。安全随机数生成器当然不具有此属性（它们通常使用外部熵作为种子-具有连续的种子-具有循环的安全哈希函数）。也就是说，作为密码的随机填充当然不能抵抗已知的纯文本，因为它将返回密钥流数据。
$ \ endgroup $
–马腾·博德威斯♦
2011-12-29 18:49
$ \ begingroup $
实际上，我的第一个方法是直接与key1进行xor（当文本超过key时使用mod），然后是key2 >> 64位状态，但是非常弱。
$ \ endgroup $
–约书亚
2014年12月15日在22:37
#5 楼
由于没有人真正回答以下问题：如果您始终对每条消息使用不同的随机初始化矢量（IV），则AES仅能抵抗已知文本攻击。为了简化起见，AES将密钥与IV组合在一起以生成密码，并且在整个消息长度的基础上，密码将在前一个块的基础上逐个旋转。只要IV对消息是唯一的（不必保密），那么不仅无法恢复密钥，而且消息中某处匹配明文-密文的知识也不会提供有关消息中任何其他地方的信息。消息。另一方面，如果密钥和IV在消息之间重用，则相同的明文将导致相同的密文，因此您可以使用足够大的已知匹配明文语料库对消息进行解密。 /密文对，即使没有恢复密钥也是如此。
评论
$ \ begingroup $
（1）您所谈论的是具有操作模式（CBC）的AES，但问题和其他答案仅涉及没有该模式的分组密码。您是说采用某种操作方式的AES答案是不同的吗？ （2）您使用的已知明文攻击的定义是什么？对于使用相同密钥的每次加密，密文是否随机出现，都不会影响攻击。
$ \ endgroup $
– Artjom B.
15年12月7日在20:50
#6 楼
实际上，我们可以做得比以下更好：或选定的纯文本”假定您具有加密为密文z的纯文本a。
AES有两个步骤可以共同阻止已知的纯文本攻击。
出于解释目的而简化的实际回合密钥和sbox步骤将类似于密钥k，密文z = sbox（a * k），其中sbox是通过查找表的简单替换。每个字节将替换为表中的相应字节。
想象一下AES加密等于sbox（a）* k。已知的纯文本攻击将如下发生：
\ begin {equation}
sbox（a）\ cdot k = z \\
k = \ frac {z} {sbox（a）}
\ end {equation}
密钥已经计算出。但是，AES的设置更像sbox（a * k），因此已知的纯文本攻击看起来像这样： > \ end {equation}
没有办法隔离k，因为我们需要知道k的值才能知道替代值是什么。换句话说，我们有一个表达式* a * k，因为我们不知道k，所以我们尚不能求解数字。不能在sbox中替换表达式，因此无法计算密钥。因此，已知的明文攻击已被阻止。
评论
$ \ begingroup $
实际上，如果AES就是这么简单，那将很容易。 $ k = \ text {sbox} ^ {-1}（z）\ cdot a ^ {-1} $。当然，AES实际上要复杂得多。我们怎么知道没有更复杂的方法来重新获得密钥->好，归结为我所说的“很多聪明的人都在考虑它；没有人提出一种实用的方法”
$ \ endgroup $
–雨披
18年11月16日在4:33
$ \ begingroup $
@poncho，您的观点正确。我的示例是一个极大的简化，使所有内容都易于理解。实际上，AES紧随其后。因此，AES的更精确但仍然较大的简化如下：$$ z = {sbox（a \ cdot k_1）+ k_2} $$ $$ sbox（a \ cdot k_1）= z-k_2 $$ $$ sbox ^ {-1}（sbox（a \ cdot k_1））= sbox ^ {-1}（z-k_2）$$ $$ a \ cdot k_1 = sbox ^ {-1}（z-k_2）$$ $ $ k_1 = \ frac {sbox ^ {-1}（z-k_2）} {a} $$ $$ Where \ k_1 \和\ k_2 \是从\ key \ k派生的。$$我确定您现在可以看到sbox如何阻止已知的明文攻击。请发表评论以进一步澄清。
$ \ endgroup $
– Aadhithya Kannan
18-11-17在17:16
$ \ begingroup $
不，我不明白您的示例如何证明AES如何抵抗KPA。在您的示例中，如果我们有两个纯文本/密文对$（a，z）$和$（a'，z'）$，则有$ z'-z = sbox（a'\ cdot k_1）-sbox（a \ cdot k_1）$;只需对可能的$ k_1 $值进行简单扫描即可恢复它（并且可以轻松覆盖$ k_2 $。再次，AES实际上要复杂得多；我们如何知道还没有更复杂的密钥恢复机制？我仍然得出结论，我对“很多聪明人……”的回答仍然是我们唯一的真实回答。
$ \ endgroup $
–雨披
18年11月17日在19:11
$ \ begingroup $
也许我不明白您的问题，但是对可能的$ k_1 $值进行“简单扫描”并不是一件容易的事。在最简单的AES版本（AES 128 ECB）中，$ k_1 $和$ k_2 $的长度均为16个字节（128位）。对每个可能的k_1_1值的扫描都必须经过2 ^ {128} $（340万亿亿亿亿美元）的不同组合。当然，这是最坏的情况，但仍然如此。最重要的是，在AES 128 CBC中，每个密码块都取决于之前的密码块。这意味着将有一个在块之间变化的附加变量。
$ \ endgroup $
– Aadhithya Kannan
18-11-18在23:13
$ \ begingroup $
我不知道是否存在尚未发现的攻击。我的意思是，抵制KPA的主要防线是制衡。如果不是针对sbox，那么到现在密码学家已经可以在AES上成功执行KPA。原因是通过sbox确保AES不能表示为线性方程。如果可以以此方式表示AES，则可以轻松地为该密钥求解方程组。
$ \ endgroup $
– Aadhithya Kannan
18年11月20日在3:07
评论
@owlstead我认为可以说填充oracle攻击是已知的纯文本攻击，因为尽管有已知的“纯文本”（即填充算法），但知道纯文本消息并没有真正帮助首先就不需要攻击的事实。@owlstead您将必须更加具体，因为我仍然只看到填充或验证预言，这些预言或预言使您可以使用selected-cipher-text-attacks恢复纯文本。
@jbtule我们是否可以同意填充oracle攻击需要有关纯文本（填充）和所选密文的知识？我只是在评论中指出，已知的纯文本可能有助于某些攻击。这与已知的纯文本攻击不同，这只是对发问者的警告。通过XML加密攻击，甚至可以推断出更多有关纯文本的知识。