Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 10 Mar 2014 21:48:34 +0100
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Reload pot file

On 2014-03-03 21:14, magnum wrote:
> On 2014-03-03 10:05, magnum wrote:
>> On 2014-03-03 05:08, magnum wrote:
>>> A different approach - and maybe quicker unless the above is simpler
>>> than I imagine - would be to do it more like cracker.c does when
>>> cmp_exact() returns true. I'd need to process the "hash:plain" into
>>> binaries, salts, sources and plains as if it came from a running format
>>> after a crack loop.

Current bleeding-jumbo includes this. My first version did not have any 
bitmap-aware code path (I had the idea it wasn't doable with the data at 
hand) but once I saw sync times of 150 *seconds* (wall clock time of 
syncing 2,800 pot entries to a process with some 650,000 NT hashes 
loaded iirc), I realized I just had to do fix that. Using the bitmap, 
the same operation went down to 10 milliseconds, lulz %-)

I still see one case of performance hit: If I attack the Gawker dataset 
starting with an empty pot file and running single mode, the first 
couple of minutes have a few occasions with up to 3.8 seconds of sync. 
But on the other hand, tens of thousands of passwords are removed in 
that time and if it wasn't for the fact salts are so heavily reused we'd 
got a great win from removed salts. So I think this should default to 
being active with no special options.

magnum

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ