[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20060531032940.GB2292@openwall.com>
Date: Wed, 31 May 2006 07:29:40 +0400
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: Parallalizing John the Ripper
On Tue, May 30, 2006 at 03:33:37AM +0200, Otheus (aka Timothy J. Shelling) wrote:
> My problem with john.pot getting corrupted was fixed by adding -DOS_FLOCK to
> the CFLAGS for linux.
That's weird, for two reasons:
1. The default arch.h for sane platforms defines OS_FLOCK already.
2. logger.c uses direct write(2) syscalls on pieces of data no larger
than POT_BUFFER_SIZE and consisting of a whole number of entries (no
partial lines). The default POT_BUFFER_SIZE is 4 KB - the same as or
smaller than the page size on most architectures. So even when OS_FLOCK
is not set, concurrent writes to john.pot by multiple instances of John
will most likely not result in john.pot getting corrupted.
> However, it looks like on restore, there is still the problem with
> overlapping keysets. Uhm, when the single-tasking john does a restore from
> a record file, does it restart from the last crypt attempt, or the last word
> that was generated? This would of course make a big difference in my scheme.
Neither. It will often try some candidate passwords for a second time.
There are several reasons for this, including the fact that many hash
implementations in John process multiple candidate passwords in parallel
(for bitslice DES on AltiVec or SSE2, that's 128 candidate passwords
processed in parallel) and that "single crack" buffers up to that number
of candidate passwords for each salt separately. So with 100,000 hashes
loaded and 128-bit bitslice vectors, there will be up to 12.8 million
candidate passwords buffered while in "single crack" mode - and those
will have to be tried again if the session is interrupted and restored.
Unfortunately, fixing this would result in much worse "single crack"
performance for sessions that are not interrupted/restored. Other
cracking modes are not impacted so badly.
--
Alexander Peslyak <solar at openwall.com>
GPG key ID: B35D3598 fp: 6429 0D7E F130 C13E C929 6447 73C3 A290 B35D 3598
http://www.openwall.com - bringing security into open computing environments
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.
