Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 27 Feb 2018 17:36:15 -0600
From: Adam Lininger <arlininger@...il.com>
To: john-users@...ts.openwall.com
Subject: Re: Getting full performance out of multiple GPU's

Thanks Alexander. That gives me a much better understanding of how JtR does
things internally also. I believe I will have much better luck with this
guidance.

Adam

On Tue, Feb 27, 2018 at 4:11 PM, Solar Designer <solar@...nwall.com> wrote:

> On Tue, Feb 27, 2018 at 03:59:44PM -0600, Adam Lininger wrote:
> > Thank you for the help. I believe I am properly using a GPU and the
> actual
> > hashing is being done there. The nvidia-smi command seems to agree. Based
> > on your email, I suspect the problem is that the korelogic rule
> generation
> > is still happening on the CPU rather than the GPU. Is there an easy way
> to
> > correct that? I've copied my command below.
> >
> > john --wordlist=rockyou.dict --format=descrypt-opencl
> > --devices=1,2,3,4,5,6,7,8 --fork=8 --rules=korelogic htpasswd
>
> Yes, it's one of those cases where you'll have to use --mask, and this
> prevents you from using solely the KoreLogic rules - at best, you may
> add a mask on top of them, but a mask would push many candidates beyond
> the length of 8, which is the maximum for descrypt, making this approach
> not entirely reasonable.
>
> You may have better luck running the rules against your descrypt hashes
> on CPU, and using your GPUs for something like:
>
> john --incremental --mask='?w?a?a?a?a' --format=descrypt-opencl
> --devices=1,2,3,4,5,6,7,8 --fork=8 htpasswd
>
> This will output something like:
>
> Loaded 1 password hash (descrypt-opencl, traditional crypt(3) [DES OpenCL])
> Warning: MaxLen = 13 is too large for the current hash type, reduced to 4
>
> The warning is OK - it means that JtR correctly reduced incremental
> mode's maximum length to 4 due to descrypt's maximum of 8 and mask of 4.
>
> You could also want to use the --min-length and --max-length options to
> split this into several invocations of JtR varying by length (perhaps
> from 5 to 8), so that you keep track of what lengths have already been
> exhausted vs. not yet.  You'll probably complete lengths up to 7
> inclusive within a day, and then focus on length 8 for some days more
> (if for one hash; otherwise multiply by the number of different salts).
>
> Alexander
>

Powered by blists - more mailing lists

Your e-mail address:

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