我正在使用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的评论是：
Do key setup based on a hash of the key string
将SHA5-256或SHA2-512交换MD5算法会对加密强度产生任何理论或实际差异吗？
解决方法
你的问题的直接答案是“不” – 它不会对加密强度产生任何明显的影响.是的,MD5已经坏了,但实际上它的弱点并没有对这个特定的应用产生任何影响. AES的密钥大小为128,192和256位.你在这里所做的就是为一个密钥创建一个字符串假名(16个字节,24个字节或32个字节).当加密专家说散列函数是
broken时,它们的意思是,给定已知的散列输出,计算与原始消息不同的消息是可行的,原始消息也散列到相同的输出.换句话说,为了使散列函数的加密强度或弱点具有任何含义,恶意方必须已知二进制密钥,这意味着只有在您的安全性已经完全失败时它才是相关的.
散列算法的强度完全与非对称密码的强度无关.
然而…
但是,更严重的问题是代码中缺少腌制.除非您计划手动加密消息(不太可能),否则您的通信很容易受到重播攻击.如果您使用ECB模式,这将无穷大,但如果没有腌制,这对于任何模式都是一个主要的安全问题. “Salting”意味着在加密之前在消息的IV或头部注入足够大的不可预测的非重复值.
这凸显了DCPCrypt的一个巨大问题. DCPcrypt的大多数用户对密码学的了解不足以理解正确腌制的重要性,并且将以完全相同的方式使用加密组件.当你以这种方式使用DCPcrypt时(非常自然),DCPcrypt不会加盐.实际上,它将IV设置为零.它变得更糟……如果你选择了一种密钥流式的链接模式(非常受欢迎),并且你的IV习惯性地为零,那么如果知道或猜到单个明文消息,你的安全性将完全被彻底打破,(甚至只是消息的一个片段被猜到). DCPcrypt确实提供了一种初始化二进制密钥(而不是字符串)的替代方法,同时允许用户设置IV(您必须自己生成随机IV).下一个问题是整个IV管理变得有点复杂.
泄露
我是TurboPower LockBox 3的作者.Dave Barton的DCPcrypt,一个令人钦佩和全面的工程工作,是我写LockBox 3的灵感之一.