| |||||||||||||
crypt_blowfishcrypt_blowfishPosted Feb 9, 2006 10:32 UTC (Thu) by kleptog (subscriber, #1183)Parent article: crypt_blowfish
One issue is ofcourse that if someone cracks the *algorithm* then it doesn't matter how difficult you make it, you're screwed.
Still, I'm not too knowledgable about this. I'm not sure if attacks on an algorithm at 32 rounds makes it a lot easier to attack the 64 round version. Also, I'm not sure if it is provable that n+1 rounds is always harder than n rounds and that there no mysterious number k where the cracking becomes trivial...
Is there much research in this direction of algorithm strengthening?
(Log in to post comments)
crypt_blowfish Posted Feb 9, 2006 21:46 UTC (Thu) by kamil (subscriber, #3802) [Link] I think you have a point.
Adding to what you wrote, we should not forget that the primary problem in real world are weak passwords, not weak algorithms.
Elaborating, with ever faster computers, ever more passwords have to be considered weak. So stronger algorithms are fine, but I believe that they have to be coupled with stronger passwords to give you real security boost. A chain is as strong as its weakest link...
This brings next problem: most people have difficulties remembering long passwords of semi-random characters (and these are the most secure). So we must face the fact that strong, i.e. long, passwords are not going to happen, if people need to memorize them.
Finally, if the password length remains limited, then password cracking becomes not that much a computational problem, as a storage problem. All you need to do is to generate a hashed version of every possible 8-letter combination and store it, sorted by hash. This problem parallelizes perfectly, so the algorithm complexity is not that relevant. After all, you only need to create the database once. And guess what? Storage capacity increases faster than CPU speed...
What saves us to an extent is "salt". With DES-like passwords, salt was a 10 or 12-bit (I don't quite remember) random value, used to artificially extend the password. I'm guessing that these new algorithms use a much longer salt, so that the disk capacity required for a complete database remains impractical. Now the question is: to what extend are current cryptographic algorithms analysed for a case where some/most bits of the key are known? (you need to store the salt in plain text along with the hash in the password file).
crypt_blowfish Posted Feb 11, 2006 11:38 UTC (Sat) by fergal (subscriber, #602) [Link] If you increase the salt or even throw in a per-machine salt then generating and keeping the database becomes impractical and pointless.
|
|||||||||||||