使用简单的键拉伸方法(如下面的Python示例)与类似于PBKDF2的方法相比有哪些缺点?目的是增强AES加密文件以防止暴力。
对于琐碎的方法有什么关键的问题吗?在我正在编程的语言中没有可用的PBKDF2实现。
for _ in range (100000):
key = hashlib.sha256(key).hexdigest()发布于 2017-02-10 23:21:22
PBKDF2的安全性论点比您的建议要好。这并不意味着您的建议更不安全,只意味着PBKDF2更容易被证明是合理的。
这是因为PBKDF2包含了三个额外的想法,而不仅仅是您的迭代建议。首先,PBKDF2显式地包含了一个salt,而您的示例没有。即使您隐含地假设key会类似于salt + password,密码加扰器确实应该将密码和salt作为单独的参数。
第二,PBKDF2迭代的不是像sha-256这样的公共哈希函数,而是一个伪随机函数 ("PRF"),比如hma-sha-256,用密码进行键控。这是一个非常微妙的理论点,但这意味着PBKDF可以处理比SHA-256这样的完整哈希函数更弱的函数。
第三,PBKDF2不仅链接PRF的输出,而且还链接它的输出XOR。这是一种(可能是偏执的)防范弱PRF的安全措施,当它们将其应用于自己的产出时,PRF周期较短。
PBKDF2 2实际上非常简单.很简单,外行不太可能把它搞砸。如果您的语言和库有SHA-256,那么它们可能也有HMAC-SHA-256,但如果不是,也很容易实现。所以你真的应该试一试--坚持标准的,经过良好检验的技术,而不是自己做。
最后注意:哈希函数的输出是二进制数据,实际上应该这样处理。也就是说,在您的示例中使用hexdigest是浪费的,不利于高质量的代码;数据应该尽可能以其本机类型处理!(使用十六进制摘要还会给出不正确的PBKDF2实现。)
发布于 2017-02-10 14:45:31
来自维基百科:键拉伸:
..。用来制造一个可能很弱的钥匙..。通过增加测试每个可能的密钥所需的时间,以更安全地抵御暴力攻击。
由于像SHA-2这样的散列是为快速、简单的键拉伸而设计的,所以仅使用散列并不能真正减慢攻击者的速度,而攻击者试图基于弱输入强制键。与PBKDF2一样,KDF的设计目的是通过减慢自己的速度来真正降低攻击者的速度。
虽然您的示例进行了大量迭代以降低计算速度,但攻击者可以创建一个包含所有有趣的弱输入及其输出的数据库,并在以后的多次蛮力攻击中使用此预先计算的值,而不是在攻击时重新计算所有值。这就是为什么像PBKDF2这样的算法额外使用一个盐来极大地增加这样的数据库所需的内存和创建它的时间,从而使它变得不切实际。
在我正在编程的语言中没有可用的PBKDF2实现。
如果该语言已经提供了一种计算散列的方法,并且您仍然愿意创建一些KDF,那么实现PBKDF2或其他设计良好的KDF应该不会太难。
https://security.stackexchange.com/questions/150972
复制相似问题