使用 AES 将 16 字节数据加密为单个块的安全性如何？没有盐/IV，没有操作模式，数百万个不同的 16 字节块被加密。我对加密的了解不够，但这对我来说很陌生。
编辑：为了提供更多细节，这不是关于加密消息，而是关于纯文本长度恰好为 16 个字节的数据库表列。数据不是完全随机的（前 8 个字节通常是相同的），并且有一个校验和来识别成功的解密。
我将在下周与提出此建议的人开会，如果有问题，我将非常感谢一些参考材料的指针，我可以用它们来证明设计是不安全的。我对该系统并不完全熟悉，但我认为这可能需要进行重大的重新设计才能解决，因此可能会遇到很多阻力。所涉及的大多数人（和权力）都在业务方面，其动机是获得一个工作系统......
【问题讨论】：
标签： encryption cryptography aes
ECB 对于一般用途来说并不安全。给定的纯文本总是加密为相同的密文，因此可以揭示模式。但是，在某些特殊情况下它是安全的，这个应用程序可能就是其中之一。
引用 Applied Cryptography， 第二版 pg。 190，关于分组密码的 ECB 模式：
从好的方面来说，没有安全性 加密多条消息的风险 用相同的钥匙。事实上，每个 块可以被视为一个单独的 使用相同密钥加密的消息。
稍后（第 208 页），Schneier 说：
如果简单和速度是您的主要目标 担心，欧洲央行是最简单的 使用分组密码的最快模式。它 也是最弱的。除了是 容易受到重放攻击，一个 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 确实适用，并且该值应该与密钥本身一样保密。彩虹表可用于加速对不使用盐的密码的暴力攻击；这是你的薄弱环节。
【讨论】：