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.