Performance issues with PBKDF2WithHmacSHA1

[tozny]

Performance issues with PBKDF2WithHmacSHA1

[SyntaxPolice]

In fact, in order to make it harder to brute force passwords, that algorithm is intentionally slowed down by doing a large number of rounds.

If you want to speed up your app, you could consider moving key generation to a different thread or caching the result of the computation so you don't have to run it multiple times. Alternately, at reduced security, you can lower the iteration count until performance is acceptable. The minimum count is 1000 but there is no "correct" number; it's really a trade-off on acceptable performance vs. threats.

You can alter this line in your copy of the library to lower the iteration count:

private static final int PBE_ITERATION_COUNT = 10000;

As with changing the algorithm, you would indeed have to transition from the old key generation method to the new one for existing users, since the resulting keys will be different for a different number of rounds. You could store the # of iterations in a preference or something as that number is not considered a secret.

We've had some requests to parameterize these and other constants, so if you're interested in helping out, we'd consider pull requests!

isaac

[ScottPierce]

Thanks for your prompt response. I understand a bit better now.

Why do you say that the minimum count is 1000? It looks like the PBEKeySpec implementation just checks that the iteration count is greater than zero.

[SyntaxPolice]

1000 is the minimum recommended by IETF and NIST. I don't think it'll break anything to reduce it further, except security:

http://dx.doi.org/10.6028/NIST.SP.800-132
https://tools.ietf.org/html/rfc2898#page-8

peace,

isaac

[ScottPierce]

I see. Makes sense. Do you have any thoughts on the API? What's somewhat tricky is that the user will need to maintain the exact same settings each time the SecretKeys are generated.

Would this be per SecretKeys creation, or a static setting that would effect all SecretKeys?

[SyntaxPolice]

It does have to be the same per key. Actually storing it next to the serialized key/salt/IV is probably the right thing. That would be a good addition to the library. So wherever you store the key, store its iteration count too.

[ScottPierce]

It would need to be backwards compatible. Probably defaulting to 10000 if it can't find the stored number of iterations.

[SyntaxPolice]

That sounds right, although I know nothing if your application logic.

Note you can convert the existing keys, but only by re-encrypting your ciphertext, e.g.

PBEKey = (10,000)
plain  = decrypt (PBEKey, ciphertext)
newPBEKey = (9,000)
newCiphertext = encrypt (newPBEkey, plain)

Must be done w/ extreme care so as not to lose ciphertext.

peace,

isaac