On: Password Cracking AES-256 DMGs and Epic Self-Pwnag...

[oakenshield]

> I wonder if the C implementation is much faster

Very likely -- Run this on your machine and see if it improves things http://stackoverflow.com/a/9781943. I got about 18.6s for your python code while this one with a 16 byte salt and 250k iterations runs in 0.6s.

OWASP recommends over 100k iterations too: https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet...

[thomas-st → oakenshield]

True, looks like it's important to use a C module if available:

In [13]: from M2Crypto.EVP import pbkdf2

In [14]: %time pbkdf2('mypassword', open('/dev/urandom').read(16), 250000, 32) CPU times: user 1.16 s, sys: 0.02 s, total: 1.18 s Wall time: 1.18 s

[oakenshield → thomas-st]

I may not understand the whole context, but if you're using PBKDF2 for key derivation, you don't want to use something that works "fast". You want whatever algorithm/iteration combination that is as slow as possible [1], but not too slow that it annoys the user.

[1] on modern hardware, that is.

[moonboots → oakenshield]

The kdf should be as slow as possible for an attacker but fast enough for you. If you're using python and the attacker is using C, you can increase security with no usability loss by switching to C and raising the iteration count.

[jgeralnik → oakenshield]

Using a slow implementation of PBKDF2 is not going to slow down attackers who use a fast implementation.

[oakenshield → jgeralnik]

Correct. I didn't mean slow implementation, I meant slow enough on modern hardware using the fastest implementaiton.