从PBKDF2生成的AES 256位密钥的安全性
我正在使用CryptoJS AES 256加密：
CryptoJS.AES.encrypt(realData, generateKey(passphrase), {iv: iv});秘密是通过以下方式产生的：
function generateKey(passphrase) {
const salt = CryptoJS.lib.WordArray.random(128 / 8);
const key256Bits = CryptoJS.PBKDF2(passphrase, salt, {
keySize: 256 / 32,
iterations: randomNumber,
});
return key256Bits;
}我对此很陌生，我想知道上面256键位有多安全？
有人可以使用蛮力来找出256键位的十六进制，base64编码字符串，iv而不关心密码。
然后转换真实256密钥位，iv用来解密realData在AES加密？或者256位键可以是蛮力吗？
谢谢!
回答 1
Cryptography用户
发布于 2021-06-24 06:35:08
iterations: randomNumber的值不应该是随机数。这是一个控制PBKDF2成本的迭代计数。它应该在应用程序中设置得尽可能高，并且PBKDF2对密码搜索提供的保护与该参数成线性增长。在下面的文章中，我假设一个较高的iterations (比方说基线为10万)，并且salt会以某种方式被存储。我还假设它使用的是HMAC-SHA-1 (默认值)或HMAC-SHA-256 (也是常见的)。
据我们所知，我们所描述的密码的主要缺点是可以通过运行generateKey来测试密码，然后使用已知的AES密码测试相应的密钥。这是“不关心密码”吗？对我来说还不清楚。
问题是，攻击者可以使用GPU、FPGA或ASIC以非常高的速度运行PBKDF2。当iterations很高时(正如它应该的那样)，PBKDF2是generateKey和密码搜索的瓶颈。因此，对手可以使用CryptoJS搜索比普通用户快几个数量级的密码。从使密码搜索困难(这是问题的主要目标)的角度来看，当涉及到强大的对手时，PBKDF2是键拉伸最不可能使用的备用CPU电源之一。更好的选择是: Argon2，scrypt，甚至bcrypt。
你会决定NIST 以前推荐的PBKDF2 2和仍然没有强制使用更好的东西是否巧合，就像它以前推动对偶_EC_DRBG一样，其明显的意图是允许美国情报部门破译这一密码。汉伦的剃刀可能适用，但我认为NIST的科学家更受尊敬。
https://crypto.stackexchange.com/questions/91718
复制相似问题
腾讯云开发者
