Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 17 Jan 2012 11:57:44 -0500
From: Rich Rumble <richrumble@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: Fork=n

On Thu, Sep 22, 2011 at 10:50 PM, Solar Designer <solar@...nwall.com> wrote:
> On Thu, Sep 22, 2011 at 10:16:47PM -0400, Rich Rumble wrote:
>> Actually I didn't even notice until you did: (contest thread)
>> On Fri, Aug 5, 2011 at 11:33 AM, Solar Designer <solar@...nwall.com> wrote:
>>  With --fork, it turns out that john.pot is not updated on its own, at
>>  least not by child processes.  You have to "killall -1 john" to get it
>>  updated, or interrupt john (but then you can't easily restore).  I am
>>  using the "killall -1 john" approach before I take john.pot's for
>>  uploads to the contest server now.
>
> Oh, you're correct, and I did not recall correctly.
Sorry to bring this thread back up again, something I noticed using
the -fork code from the contest is that each fork acted as it's own
single john instance (seems obvious) and thus the password hashes
are loaded for each, not shared like in OMP. I only *really* noticed
because I had a large DES file I was playing with and noticed how large
my memory consumption got. Again I'm not sure if this code is
going to make it back into JtR in a meaningful way, but if it did "sharing"
the hash file might be a good thing. OMP and or MPI may do what
-fork/node was doing in a better way. I'm just toying around right now
with this contest build vs a recent OMP build for giggles.
-rich

Powered by blists - more mailing lists

Your e-mail address:

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