使用AES将16字节数据加密为单个块有多安全？没有盐/ IV，没有操作模式，数百万个不同的16字节块被加密。我对加密知之甚少，但这对我来说很有气味。
编辑：提供更多详细信息，这不是关于加密消息，而是数据库表列，其中纯文本长度恰好是16个字节。数据不是完全随机的（前8个字节经常是相同的），并且有一个校验和来识别成功的解密。
我将与下周提出这个问题的人一起开会，如果有问题，我会非常感谢参考材料的一些指示，我可以用它来证明设计是不安全的。我对系统并不完全熟悉，但我认为这可能需要进行重大的重新设计才能解决，因此可能存在很多阻力。所涉及的大多数人（和权力）都在业务方面，其动机是建立一个工作系统......
答案 0 :(得分：10)
ECB对于一般用途并不安全。给定的纯文本始终加密到相同的密文，因此可以显示模式。但是，有一些特殊情况是安全的，这个应用程序可能就是其中之一。
引用 Applied Cryptography，第二版pg。 190，关于分组密码的ECB模式：
从好的方面来说，没有安全保障 加密多条消息的风险 用同一把钥匙。事实上，每一个 可以将块视为单独的 用相同的密钥加密的消息。
后来（第208页），施奈尔说：
如果简单和速度是你的主要 关注，欧洲央行是最容易的 使用分组密码的最快模式。它 也是最弱的。除了 容易受到重播攻击的影响 ECB模式下的算法最简单 密码分析。我不推荐ECB 用于邮件加密。
用于加密随机数据，例如 其他按键，ECB是一个很好用的模式。 由于数据很短且随机， 欧洲央行没有任何缺点 对于这个应用程序。
您的案例中的公共前缀和校验位不会产生常见的密文。仅当重复整个明文块时才会发生这种情况。根据您的描述，您的申请可能非常适合欧洲央行 - 特别是如果每个纯文本值作为一个整体，是唯一的。
答案 1 :(得分：4)
没有盐，也称为初始化矢量或IV，密文的安全性（我相信，密钥也是如此）大大减少了。潜在的攻击者可以更容易地在加密文本中找出重复模式。 IIRC这是微软在升级MS Office加密方案时所犯的基本错误。
答案 2 :(得分：3)
AES非常强大，可以抵御仅限密文攻击。但是，使用相同的密钥加密大量明文会使您的系统更容易受到已知明文和选择明文攻击的攻击。</ p>
话虽如此，如果加密密钥是随机的，并且如果明文看起来是随机的，那么你可能仍然是安全的。但我肯定会考虑使用不同的密钥。
另一方面，如果明文彼此相关和/或看似随意，则欧洲央行根本不安全。
答案 3 :(得分：0)
我不知道AES短信的任何弱点。算法应该很开心。
要参加您的会议，您需要：
1）威胁模型（可能会看到他们离开或成为“坏人”时会发生什么，何时以及会发生什么。）
2）威胁模型中的一些用例。
有了这个，你应该能够确定你是否真的需要加盐AES，如果你可以在其他地方推导它，那么加密真的可以保护列中的值，使得AES的使用毫无意义。最后，问一个问题，“密钥真的比数据更安全吗？”我已经看到这样的方案，其中密钥与数据大小相同（大小=“有点小”），并且与它所保护的数据一样可访问。是的，当攻击者弄清楚你到底做了什么时，它会给你买几个小时，但它并没有给你太多的安全保障。
希望有所帮助并给你一些可以咀嚼的东西。不知道你的特定位置，很难定制答案。 ：）
答案 4 :(得分：-4)
在加密术语中，只有在攻击者知道特定算法和IV时，这才是不安全的。
做出某种假设：一旦解密，攻击者是否会知道数据看起来知道解密尝试是否成功？例如是否有MD5，CRC或某种形式的校验和可以验证成功的解密尝试？如果是这样，您可以为攻击者提供验证尝试的方法。
但就黑客而言，仍然有2 ^ 128个密钥组合（用于128位密码），这与在TB级数据上使用相同密钥一样安全。操作模式无关紧要，因为16字节的数据只有一个块，因此密码块链接（CBC）不适用。
然而，盐IV确实适用，并且该值应该与密钥本身一样秘密。彩虹表可用于加速对不使用盐的密码的暴力攻击;这是你的薄弱环节。