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

Solar,

> On a related note I have also committed the "reload on USR2" patch
> including --reload-every=N (which signals USR2 to children). The good
> news is it seem to work like a champ (although ineffective if used
> often) but the bad news is it (ie. execv) can never work under MPI
> :-(
>
> So now I'm struggling with a *real* reload, not using execv. Not
> trivial, more on that (including more questions :) later.

Not sure you can help me off the top of your head but here's my thoughts 
right now:

Simplest but slowest alternative would be to drop the database, and more 
or less reload it (from both input hash files and pot files) just like 
an initial load. A very bad effect of this is a lot of stuff can't be 
freed (mem_alloc_tiny) and it might be unnecessary slow. I tried it 
anyway since I thought it could be an easy start but it seems to be 
harder than I thought. The worst problem might be that a lot of still 
used pointers points to the old database. For these reasons I have 
abandoned this idea for now (though the mem_alloc_tiny problem could be 
solved by introducing alloc domains that can be freed, as discussed 
earlier).

A faster and safer solution would be to just re-process pot file using 
existing functions. We miss the opportunity to reload the input files 
containing hashes to crack but that was never my main goal anyway. The 
worst problem seems to be the database used during initial load is not 
exactly the same as the one ultimately used. Perhaps that doesn't 
necessarily matter?

I'm not sure but I might need to implement an alternative version of 
ldr_load_pot_file() to begin with. Anyway the hardest part for me now is 
deciding what needs to be done - and when it's appropriate to do so. I 
think this processing could take place right after crk_password_loop() 
with no side effects.

I'd appreciate any hints you can come up with!

magnum

Powered by blists - more mailing lists

Your e-mail address:

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