Date: Wed, 27 Jun 2012 20:41:55 -0500 From: "jfoug" <jfoug@....net> To: <john-dev@...ts.openwall.com> Subject: RE: --regen-lost-salts (was: 'New' functionality added to JTR (finding salted passwords, without salts)) >From: magnum [mailto:john.magnum@...hmail.com] >I saw non-uniform distribution for sure. I never got to test this >curious feature until now, when testing that last BSS patch. It's pretty >cool and faster than I thought. I ran password.lst on the first 10 >million lines in the KoreLogic md5 file, like this (btw -wo now defaults >to password.lst): Speed totally depends upon salt size, and JtR does not 'speed up' as candidates get cracked, like in 'real' salted mode. In this mode, we always test every possible salt for each password. So, OSC, was a good choice since the salt size is so tiny. The problem with OSC 're-salting', is that there is no assurance that it really was OSC, and not simply a simple password, that someone jammed 2 characters on the front of ;) Some of the other formats are much easier to 'tell' that the re-salt is really correct. A format like media-wiki is pretty easy, since it is a salt and a dash appeneded to an MD5 string. Pretty 'easy' to know you got the proper password, and re-salt in that situation. The code is not the most 'useful' thing, but I have run up against this sort of thing a few times in the past, and trying to re-gen salts outside of JtR, to use JtR in raw-md5 mode, simply took WAY too much IO. Putting it in JtR got my runs going at least 10x as fast in total throughput Jim.
Powered by blists - more mailing lists
Powered by Openwall GNU/*/Linux - Powered by OpenVZ