4 ms·
"When the standard was written in 2000, the recommended minimum number of iterations was 1000, but the parameter is intended to be increased over time as CPU sp
by mrmondo 11y ago
"When the standard was written in 2000, the recommended minimum number of iterations was 1000, but the parameter is intended to be increased over time as CPU speeds increase. As of 2005 a Kerberos standard recommended 4096 iterations,[2] Apple iOS 3 used 2000, iOS 4 used 10000,[3] while in 2011 LastPass used 5000 iterations for JavaScript clients and 100000 iterations for server-side hashing"
source: https://en.wikipedia.org/wiki/PBKDF2 https://en.wikipedia.org/wiki/PBKDF2
*Edit: Oh.. it's PBKDF1....
- sarciszewski 11y agoNope, PBKDF1 was a typo.
- logicallee 11y agohow can anyone take anything seriously that requires 1000 iterations. if iterations had an exponential function then the difference between 1000 iterations and 10,000 is ridiculous, like the difference between 16 bit encryption (no such thing, this would be a joke) and 160 bit encryption. But if it's not exponential, then adding thousands of iterations doesn't do much. Maybe instead of 1 day to break it, now it takes 1000 days, or instead of spending $4,000 on CPU time now you need to spend $4M to crack it. Big deal - it's just as broken. So can anyone explain the math here? How can they seriously suggest linearly increasing the number of iterations over time?
- sarciszewski 11y agoAttackers can use special hardware (ASICs, for example) to perform a lot of low-memory but CPU-intensive calculations quickly. Modern KDFs emphasize a property called memory-hardenss: It should be reasonably fast on consumer devices, require a reasonable amount of memory, and trading off memory usage should require an absurd CPU slowdown. PBKDF2 doesn't have this property, so if you're forced to use it, the standard recommended iteration count is 86000. 50 is a joke.
- logicallee 11y agoso it's not really exponential - if ridiculous amounts of memory somehow became very cheap and available, then it would break it? this is quite different from the exponential properties most encryption has. I would expect "ridiculous amounts of memory" to mean "more bytes than the number of atoms on Earth", that sort of thing. It sounds like rather than these kinds of theoretical limits, they chose much more practical limits - which seems a lot more dangerous and less future-proof, but I guess I'm not an expert.
- sarciszewski 11y agoAs attackers get better, we can just up the ante. More rounds, more memory usage, etc. If you're building software in 2016, you want to use one of the following for turning a password into a crypto key: - Argon2 - scrypt - bcrypt PBKDF2 should be your last resort. Don't fall back to a simple hash function.
- logicallee 11y agothat makes zero sense. something encrypted in 2001 isn't supposed to magically become plaintext in 2016 because "attackers get better." it's fundamentally not the promise of encryption. (I thought.)
- sarciszewski 11y agoUh, no. AES was originally only slated to survive until 2030. Advances in cryptanalysis are hard to predict, but attacks always get better.
- noddingham 11y agoWait what? It feels like you're trying to argue with the results of Moore's law. How does it make zero sense that what would have taken years on 1990s hardware now may only take weeks on 2016 hardware? Why do you think recommended password length and complexity has increased? Why do you think the default for RSA key length is 2048-bit now instead of 1024?