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