I want to use pbkdf2 to generate a key for a symetric encryption (DES, 3DES, may be AES) algorith, that will be used to secure private data between an AS/400 and another computer (probably running Windows).
I've been "porting" the pbkdf2 c source code from a FreeBSD repository to an AS/400 (AKA as iSeries or Power system), which is BTW not a big deal.
I have also compiled the same code on a Windows system (with Visual Studio 2012) (For those who may be interested, an API which implements PBKDF2 exists in Windows 7 and Win2008R2: BCryptDeriveKeyPBKDF2())
The performance seems good enough on Windows (I admit that the Windows machine is not a "slow machine" at time of writing: Asus R751L, Intel Core i7-4500U, 16GB ram): With password = "abcd", salt = "some salt" (I will use a 64bit or more if required random value in the real application), here are some times for several iterations count (c):
- c = 1000 => 31ms (not optimized), 15ms (optimized for speed)
- c = 10000 => 320ms (not optimized), 94ms (optimized for speed)
- c = 100000 => 3280ms (not optimized), 880ms (optimized for speed)
(FYI, the BCryptDeriveKeyPBKDF2() API gives slightly better results than the version I have compiled, but this is not my issue)
Now the problem is the execution speed I get with the AS/400 system:
- c = 1000 => 12590ms (not optimized), 2946ms (optimized)
- c = 10000 => 125889ms (not optimized), 29452ms (optimized)
- c = 100000 => (have not tried...)
My AS/400 is not a very powerful system, but even the optimized version is really slow...
Up to now, I have read that the "c" (iterations count) parameter should be as high as possible, 1000 being the recommended minimum value for "c" in the 2000's..., and that one needs to find a trade-off between acceptable performance and security, according to the involved systems; in my case, c = 1000 takes already too much time to be computed in my opinion, for several reasons:
- Application Reponsiveness,
- possible DOS attacks,
Now I am wondering: can a long and/or complicated shared secret be a solution to keep "c" as small as possible without "losing" too much "security"? (1000 for "c" is already far too slow, so I would like to use c = 100 may be...)
Is there some kind of rule, like "adding n characters to the password is somewhat equivalent increasing the number of iterations (c) of x?
Does increasing the size of the salt (e.g., 128 bits or more instead of 64 bits) increase the difficulty get back to the original data for a cracker?