Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CA+TsHUDZ+ixHhyF9qMz71BSME+-EBpokodLA-+E6WcJ0MWbGNQ@mail.gmail.com>
Date: Sat, 15 Aug 2015 07:00:48 +0530
From: Sayantan Datta <std2048@...il.com>
To: john-users@...ts.openwall.com
Subject: Re: handling of high numbers of single-salt descrypt hashes

On 14-Aug-2015 4:57 pm, "Solar Designer" <solar@...nwall.com> wrote:
>
> On Thu, Aug 13, 2015 at 10:59:21PM -0800, Royce Williams wrote:
> > I am trying to load an unusually large number of descrypt hashes (128
> > million), all with the same salt. (Yes, I know that this is bizarre.
> > :)  If the answer is "don't do that", I will be OK with that -- I can
> > use hashcat instead for this analysis, which can handle this job with
> > no problem).
>
> No, the answer is "do it".  First, please check if JtR is able to load
> those hashes fine on CPU.  It should.  Then, we'll need to get
> descrypt-opencl to work for this, too.
>
> What speeds is oclHashcat giving you for this obscure case?  How does
> this compare to JtR on CPU?
>
> Sayantan - you probably need to introduce a threshold on hash count
> after which the old-fashioned way of sending the computed hashes back to
> host would be used.  Not only for descrypt-opencl, but also for other
> formats where you implemented on-GPU hash comparison.  Just determine
> after which hash count (as well as hash count per salt, where applicable -
> so it might need to be two thresholds, then) things start to become
> worse than when having the hashes sent back to host.  Then as a separate
> task revise the OpenCL formats such that you can raise the thresholds,
> and do that.
>
> > With all six of my GPUs, I get similar results, but some of the errors
> > result in john exiting uncleanly in such a way that memory usage on my
> > GPUs not being freed up.  I know that a reboot will clear the issue,
> > but I'm not sure what other methods are possible.
>
> This sounds like a driver bug, if the john processes are indeed fully
> killed by that point.
>
> Alexander

Royce, you may experiment with LM hashes as it was built with this type of
situation in mind. I haven't tested 128 million hashes, however it should
be able to load them. Descrypt needs another revision before it's ready to
handle this many hashes.

Regards,
Sayantan

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.