[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120520150709.GA4370@openwall.com>
Date: Sun, 20 May 2012 19:07:09 +0400
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: Performance Considerations of stdin
On Fri, May 18, 2012 at 05:37:13PM -0400, Brad Tilley wrote:
> Do you think it's safe to say that so long as the word generation program
> keeps JTR at 100% CPU utilization that it's fast enough?
Usually yes, but this doesn't tell you if things are overall slower
(likely) or faster (theoretically possible) than JtR alone (with its
built-in generation of candidate passwords). Additionally, you keep
another CPU core at least partially in use by your word generation
program; you could instead use that CPU core by another instance or
thread of JtR to compute more hashes per second total.
In general, piping candidate passwords into JtR is usually wasteful when
you crack fast and saltless hashes (or when the salt count is low).
For slow and/or salted hashes, it is OK performance-wise (although you
don't achieve any speed increase in this way).
Usually, --stdin and --pipe are used not to increase the speed (which
they usually don't), but to provide a candidate passwords stream that
would be impossible or more difficult to generate with JtR itself. For
example, when you already have a program that generates your desired
candidate passwords, you may use it along with --stdin quicker than
reimplement the same functionality in terms of JtR wordlist rules or
external mode.
There's also the issue of interrupting/restoring sessions. Since
there's buffering involved (at multiple layers), you may end up skipping
some candidate passwords, or you need to compensate for that (which may
be tricky). When JtR itself generates your candidate passwords (neither
--stdin nor --pipe is in use), it takes care of this issue transparently.
Alexander
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.
