Question

我正在使用Delphi 2007中的DCPcrypt库加密内部应用程序的文本。

我目前正在使用以下代码（不是我的实际密钥）：

  Cipher := TDCP_rijndael.Create(nil);
  try
    Cipher.InitStr('5t@ck0v3rf10w', TDCP_md5);
    Result := Cipher.EncryptString('Test string');
  finally
    Cipher.Burn;
    Cipher.Free;
  end;

InitStr的评论是：

根据密钥字符串的哈希值进行密钥设置

为SHA2-256或SHA2-512交换MD5算法是否会对加密强度产生任何理论或实际差异？

Answer 1

您问题的直接答案是“否” - 它不会对加密强度产生任何明显的影响。是的，MD5已经坏了，但实际上它的弱点并没有对这个特定的应用产生任何影响。 AES的密钥大小为128,192和256位。你在这里所做的就是为一个密钥创建一个字符串假名（16个字节，24个字节或32个字节）。当加密专家说散列函数是broken时，它们的意思是，给定已知的散列输出，计算与原始消息不同的消息是可行的，原始消息也散列到相同的输出。换句话说，为了使散列函数的加密强度或弱点具有任何含义，恶意方必须已知二进制密钥，这意味着只有在您的安全性已经完全失败时它才有用。

散列算法的强度完全与非对称密码的强度无关。

然而...

然而，更严重的问题是代码中缺少腌制。除非您计划手动加密消息（不太可能），否则您的通信很容易受到重播攻击。如果您使用ECB模式，这将无穷大，但如果没有腌制，这对于任何模式都是一个主要的安全问题。 “Salting”意味着在加密前在消息的IV或头部注入足够大的不可预测的非重复值。

这凸显了DCPCrypt的一个巨大问题。 DCPcrypt的大多数用户对密码学的了解不足以理解正确腌制的重要性，并且将以完全相同的方式使用加密组件。当您以这种方式使用DCPcrypt时（非常自然），DCPcrypt执行 NOT salt。实际上，它将IV设置为零。它变得更糟......如果你选择了一种密钥流式的链接模式（非常受欢迎），并且你的IV习惯性地为零，那么如果知道或猜到单个明文消息，你的安全性将完全被彻底打破，（甚至只是消息的一个片段被猜到）。 DCPcrypt确实提供了一种初始化二进制密钥（而不是字符串）的替代方法，同时允许用户设置IV（您必须自己生成随机IV）。接下来的问题是整个IV管理有点复杂。

披露

我是TurboPower LockBox 3的作者。 Dave Barton的DCPcrypt是一个令人钦佩和全面的工程工作，是我编写LockBox 3的灵感之一。

Answer 2

您应该指定加密攻击的类型;假设使用known-plaintext attack，并且入侵者使用预先计算的哈希值来查找键字符串 - 那么使用的哈希算法之间应该没有区别，任何哈希算法都需要几乎相同的时间来查找键字符串。

使用DCPcrypt加密和哈希算法

2 个答案:

然而...

披露