Encryption 不含盐的16字节AES加密

使用AES将16个字节的数据加密为单个块有多安全？无salt/IV，无操作模式，数百万个不同的16字节块加密。我对加密技术知之甚少，但这对我来说很难闻

编辑：更详细地说，这不是关于加密消息，而是关于一个数据库表列，其中纯文本长度恰好为16字节。数据不是完全随机的（前8个字节通常是相同的），并且有一个校验和来标识成功的解密

---

我将在下周与提出这个建议的人开会，如果有问题，我将非常感谢一些参考资料，我可以用它们来说明设计是不安全的。我并不完全熟悉这个系统，但我认为这可能需要一个重大的重新设计，以获得周围，所以可能会有很多阻力。大部分相关人员（和权力）都在业务方面，他们的动机是获得一个工作系统…

无盐，也称为初始化向量或IV，密码文本（我相信还有密钥）的安全性大大降低。潜在的攻击者将更容易识别加密文本中的重复模式。IIRC这与Microsoft在升级MS Office加密方案时犯的基本错误相同。

在密码学术语中，只有当攻击者知道特定算法和IV时，这才是不安全的

有一个特定的假设：一旦解密，攻击者是否会知道数据是什么样子，从而知道解密尝试是否成功？e、 g.是否有MD5、CRC或某种形式的校验和可以验证成功的解密尝试？如果是这样，您将为攻击者提供一种验证尝试的方法

但就黑客而言，仍然有2^128个密钥组合（对于128位密码），这与在TB数据上使用相同的密钥一样安全。操作模式是不相关的，因为16字节的数据只是一个块，所以密码块链接（CBC）不适用

---

但是，salt IV确实适用，并且该值应该与密钥本身一样保密。彩虹表可以用来加速对不使用salt的密码的暴力攻击；这是您的薄弱环节。

ECB不适合一般使用。给定的纯文本总是加密为相同的密文，因此可以显示模式。但是，在某些特殊情况下，它是安全的，此应用程序可能是其中之一

引用应用密码学，第二版第190页，关于分组密码的ECB模式：

好的一面是，没有安全保障 加密多条消息的风险 用同一把钥匙。事实上，每个 块可以看作是一个单独的块 使用相同密钥加密的消息

后来（第208页），施奈尔说：

如果简单和速度是你的主要目标 担心的是，欧洲央行是最容易和最容易的 使用分组密码的最快模式。信息技术 也是最弱的。除了 易受重播攻击的攻击 ECB模式下的算法最简单 密码分析。我不推荐欧洲央行 用于消息加密

用于加密随机数据，例如 其他关键点，ECB是一个很好的使用模式。 由于数据短且随机， 欧洲央行的缺点都无关紧要 对于此应用程序

---

您案例中的公共前缀和校验位不会生成公共密文。仅当复制了整个纯文本块时，才会发生这种情况。根据您的描述，您的应用程序可能非常适合ECB，尤其是如果每个纯文本值作为一个整体都是唯一的。

AES对于仅加密文本的攻击非常强大。但是，使用同一密钥加密大量明文会使系统更容易受到已知明文和选定明文攻击

也就是说，如果加密密钥是随机的，如果明文看起来是随机的，那么您可能仍然是安全的。但我肯定会考虑使用不同的键。< /P>

---

另一方面，如果明文相互关联和/或看起来不是随机的，ECB根本就不安全。

我不知道AES在短消息方面有任何弱点。算法应该非常令人满意

要参加您的会议，您需要：

1） 威胁模型（当他们离开或成为“坏人”时，他们可能会看到什么、什么时候以及发生了什么）

2） 威胁模型中的一些用例

通过这一点，您应该能够确定是否确实需要对AES进行加密，并且，如果您可以在其他地方派生列中的值，那么加密是否真的可以保护该列中的值，从而使AES的使用变得毫无意义。最后，问一个问题，“密钥真的比数据安全吗？”我见过这样的方案，其中密钥与数据大小相同（where size=“有点小”）并且与它所保护的数据一样可访问。是的，它可以为您节省几个小时，让攻击者知道您到底做了什么，但它不会给您带来太多可靠的安全性

---

希望这对你有所帮助，给你一些思考的机会。不知道你的具体位置，很难找到合适的答案。：）

在密码学中，你假设攻击者知道算法和IV。你也假设他知道密钥吗？如何验证解密的数据？你可以权衡风险，但某些事情必须保密。我猜你还假设你的企业不受社会工程的影响…@Spolson：你假设攻击者知道absolu除了数据本身（这才是重点）之外，其他一切，以及用于加密的密钥。依赖于任何其他内容都是机密的只是模糊处理，这并不能提供真正的安全性。正如Mike Boers指出的，你假设攻击者知道除了密钥和明文之外的一切。这就是理论和实践的区别，密码学都是理论。这假设存在重复你是哪种类型的数据