java为什么我的pbkdf2实现如此缓慢（相对于SQLCipher）？

Question

我在Xoom平板电脑上编写了一个简单的Android应用程序，它只在SQLCipher数据库中存储一些字符串注释

系统会提示用户键入密码短语，SQLCipher库将使用该密码短语创建数据库。到目前为止，这工作得很好，非常顺利

现在，我还实现了一个用于身份验证的小型PBKDF2算法 （事实上，我想在将来加密一些其他文件，这些文件不能存储在数据库中）。 但现在，我只是来检查我的pbkdf2算法是否正确。 我只使用了javax。加密和java。安全libs

代码片段如下所示：

int derivedKeyLength = 128;
int iterations = 500;
KeySpec spec = new PBEKeySpec(passphrase.toCharArray(), salt, iterations, derivedKeyLength);
SecretKeyFactory f = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA1");
byte[] derivedKey = f.generateSecret(spec).getEncoded();    

salt是一个16字节的随机数，由SecureRandom生成

因此，我对密钥和salt进行了硬编码，并比较了用于身份验证的derivedKey（仅一个测试用例！）

我现在的问题是，在我的Xoom上，它会持续大约5秒，直到派生函数完成，尽管迭代只设置为500次

默认情况下，AFAIK SQLCipher使用的迭代数为4000，如果密钥错误或正确，它会立即响应。 （如果我将迭代设置为4000，则至少需要15秒）

问题是，我实现的效率有这么低，还是因为SQLCipher的性能那么好（原生NDK函数等等）

先谢谢你 p、 对不起，我的英语还没那么好

编辑：

对不起，我不太清楚：-）

我知道PBKDF2应该很慢（具体来说是迭代量，以减缓暴力攻击），这正是我要问的原因！我想将迭代次数设置为5000（这是不可接受的，超过15秒）

我只是想知道，正如我所说的，SQLCipher还使用PBKDF2（迭代=4k，而我使用500）从给定密码派生密钥。最后，我不是在谈论AES加密，只是在推导密钥时的不同

当然，SQLCipher似乎比自制的密钥派生函数快得多，但我不认为会有这么大的区别，因为SCLCipher的PBKDF2真的可以即时工作

你好

Answer 1

好吧，我知道问题出在哪里了

如果我断开设备与PC的连接，它会立即工作。如果我在那之后重新连接它

现在，即使迭代次数在5000次及以上，导出函数只需要不到一秒钟的时间！！这太棒了，因为我的Xoom并不是所有设备中最新的

可能是因为调试模式或其他原因，我真的不知道

不管怎样，多亏了斯伯拉蒂先生。希望这对将来的人有所帮助：-）

Answer 2

好的，这（见下文）并不完全是你的问题，PBKDF2速度很慢，但应该不会像硬件上的那些参数所描述的那样慢。 这里有一些关于Android PBE/KDF性能的统计数据（和提示：http://nelenkov.blogspot.com/2012/04/using-password-based-encryption-on.htmlSecretKeyFactory性能问题并非未知：Any way around awful SecretKeyFactory performance with LVL and AESObfuscator?

SecretKeyFactory可能使用纯Java实现SQLCipher有两个相关功能：

• 它使用OpenSSL，编译的本机代码（在我的桌面上），OpenSSL的PBKDF2比 用于2000次迭代的JVM6 SecretKeyFactory版本，不包括JVM启动时间。我没有 与AES的速度相比，其他人似乎也觉得Android的速度很慢。）
• 4000次迭代PBKDF2只在数据库打开时进行，之后最多有2次迭代 对于HMAC secret页面（假设默认配置，如文档所示）

你的代码似乎是正确的，不应该有这么大的（线性？）当迭代次数增加时，性能会下降。Xoom应该使用JIT运行一个非古老的JVM，你能用other code验证性能问题吗

---

PBKDF2是设计的由于预期的key stretching操作而变慢（请参见此问题的答案https://security.stackexchange.com/questions/7689/clarification-needed-for-nists-whitepaper-recommendation-for-password-based-ke）。迭代计数器允许您在速度和安全性之间进行权衡。

AES一直是intended to be fast，现在是 fast（speed comparison PDF，选择的AES候选者在那篇文章中以其原始名称Rijndael引用）

我假设您将PBKDF2计算时间直接与在SQLCipher数据库上执行SQL操作所需的时间进行比较，这几乎可以肯定是设计为快速的

有效地比较了两种不同要求的不同操作，从而得出了速度差异