非常重要的是，该数据库的每个条目都是使用不同且唯一的密钥加密的。如果在这种特定情况下使用CBC模式切换到AES，我们是否可以获得任何安全性？相同的密钥来加密每个条目。如果攻击者闯入我们的数据库并窃取我们的数据，那么他需要利用多少条目才能利用ECB弱点并能够解密信息？
对于最后一种情况，我想我想要如果攻击者仅拥有大约10条加密消息，就会发现攻击者是否可以解密某些AES ECB加密数据。
谢谢！
#1 楼
仅给出您所说的内容，并假设密钥以强大的方式创建和存储，使用其他密钥对数据库条目进行加密可以缓解ECB模式的问题。即，相同的明文在用相同的密钥加密时，总是输出相同的密文。切换到CBC模式无法获得任何安全性（假设您可以轻松地安全地存储所有密钥，但是请参阅@Thomas Pornin所说的话）。切换到CBC模式的实际好处是您只需要安全地存储一个密钥即可。通常不需要保护IV。在第二种情况下，对于ECB模式下的所有条目都使用完全相同的密钥，攻击者可以获得的好处是，如果他知道明文/密文对，他现在知道到处都是明文出现在整个数据库中。
例如，假设攻击者自己的信息恰好在数据库中。他可以查找自己性别的加密版本。现在，他知道数据库中其他所有人的性别（如果密文与他的密文相同，则他知道该条目是男性的，否则是女性的）。可以将相同的想法扩展到其他字段（年龄，名字，姓氏等）。此优势的关键在于，攻击者必须具有纯文本/密文对。
#2 楼
当用相同的密钥加密两个块时，ECB的麻烦就开始了。如果系统中的每个插槽都有其自己的密钥，而该密钥曾经仅用于加密一个块（这意味着在修改数据片段时，您还使用了新密钥），那么ECB不会有问题。如果您重复使用密钥（如果只是按时间使用）（使用新值更新条目，并使用与先前值相同的密钥对新值进行加密），则会遇到ECB问题。但是，这就引出了以下问题：如果您可以安全地存储那么多密钥，为什么仍要使用AES？您可以将数据片段本身存储在该位置。
我想您的不同密钥实际上是根据给定的主密钥和与每个数据库行关联的一种计数器动态生成的（例如MySQL的“自动增量”字段）。在那种情况下，如果将主密钥和计数器值组合到特定于行的密钥的密钥派生过程相当安全（例如，这是HMAC / SHA-256，则通过以主密钥作为密钥的计数器计算得出） ，那么您甚至可以完全省去AES：只需对生成的特定行“密钥”与要加密或解密的数据进行异或运算即可。另一方面，如果密钥派生过程比较粗糙，那么即使使用AES，也可能存在隐患。将类似的密钥与AES一起使用可增强AES抵抗相关密钥攻击的能力，并且AES尚未设计成可抵抗这种攻击（这不是选择标准的一部分）。
评论
$ \ begingroup $
感谢您的评论，托马斯。一旦我们使用相同的密钥来加密2个不同的纯文本块，我将考虑您所说的解决ECB问题。另一方面，我们不是自己存储密钥。我们保存的加密文本由客户端发送到我们的服务器，并且已经被加密。我只是想知道，如果攻击者拥有一个数据库，该数据库包含大量以ECB模式用AES加密的条目，以便对该信息进行解密（如果可行的话）。
$ \ endgroup $
– jjsanchez
11-10-25在11:16
评论
ECB模式的主要问题在于，相同的明文块（用相同的密钥加密）总是导致相同的密文块（而不同的密文块导致不同的密文块）。请问这是您的问题吗？事情取决于攻击模型。如果假定对手以几种状态获得加密的数据库，则以ECB模式单独加密每个条目都是较弱的（即使使用唯一的关键字也是如此），因为它可以区分已更改的条目。特别是，如果每个条目都可以采用两种状态，则足以以一种已知状态获得加密数据库，从而能够轻松解密数据库的任何其他加密状态。