Slashdot Mirror
John the Ripper Cracks Slow Hashes On GPU
solardiz writes "A new community-enhanced version of John the Ripper adds support for GPUs via CUDA and OpenCL, currently focusing on slow-to-compute hashes and ciphers such as Fedora's and Ubuntu's sha512crypt, OpenBSD's bcrypt, encrypted RAR archives, WiFi WPA-PSK. A 5x speedup over AMD FX-8120 CPU per-chip is achieved for sha512crypt on NVIDIA GTX 570, whereas bcrypt barely reaches the CPU's speed on an AMD Radeon HD 7970 (a high-end GPU). This result reaffirms that bcrypt is a better current choice than sha512crypt (let alone sha256crypt) for operating systems, applications, and websites to move to, unless they already use one of these 'slow' hashes and until a newer/future password hashing method such as one based on the sequential memory-hard functions concept is ready to move to. The same John the Ripper release also happens to add support for cracking of many additional and diverse hash types ranging from IBM RACF's as used on mainframes to Russian GOST and to Drupal 7's as used on popular websites — just to give a few examples — as well as support for Mac OS X keychains, KeePass and Password Safe databases, Office 2007/2010 and ODF documents, Firefox/Thunderbird/SeaMonkey master passwords, more RAR archive kinds, WPA-PSK, VNC and SIP authentication, and it makes greater use of AMD Bulldozer's XOP extensions."
SRP is great, but it does not eliminate the need for better password hashing - rather, these things may/should be used together. It does not take breaking DH to merely probe candidate passwords against a stolen/leaked SRP verifier. The Wikipedia article you referenced says that "using of functions like PBKDF2 instead of H for password hashing is highly recommended", and they were referring to the password stretching aspect. Other properties of the hashing method are also relevant, just like they are to "regular" password hashes.
In fact, I complained to Tom Wu about SRP's use of non-iterated SHA-1 in 2000, and I had an e-mail exchange on a similar topic in SPEKE context with David Jablon in 1998 or so. Since then (or at about that time), the need for heavy to compute underlying hashes even along with zero-knowledge password proofs became widely recognized. I am not really into the latter topic, but I did my little bit to influence that field in that minor aspect (and I'm sure many others did as well).