[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <022e01cd54cf$330e48b0$992ada10$@net>
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
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
