Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 20 Nov 2013 08:24:26 -0600
From: Richard Miles <richard.k.miles@...glemail.com>
To: john-users@...ts.openwall.com
Subject: Re: Questions and suggestions to build a home cracking
 box. :)

Hi Magnum,

First of all, thanks so much for this great answer and very detailed.

I'm answering / commenting / asking inline.

Thanks.

On Wed, Nov 20, 2013 at 2:07 AM, magnum <john.magnum@...hmail.com> wrote:

> On 2013-11-20 06:47, Richard Miles wrote:
>
>> I will be using exclusively John The Ripper tool, no other tools such as
>> hashcat. I will be running Linux (32 or 64 bits?).
>>
>
> You should definitely use 64-bit. The performance is always better and
> sometimes significantly so.
>
>
Great, I will take this in consideration.


>
>  1) Modern processors contains multiple cores and threads (there are some
>> good processors with 4 cores and 2 threads per core = 8 cores). Most of my
>> cracking tasks will be exclusively against one single password hash,
>> consequently use --fork or spawn multiple process will be useless,
>> correct?
>>
>
> On the contrary, OMP and fork is beneficial even if you attack only one
> hash. You can try n passwords at a time instead of just one.
>
>
This is cool. I was not aware that fork was able to work on a single hash.
I tried OMP before but it was not very stable, sometimes it worked,
sometimes not, so I would like to avoid it, except if it's stable now. :)

Between OMP and Fork what is faster? Both support all password hashes
available on your github (https://github.com/magnumripper/JohnTheRipper)?


>
>  2) Is there a reliable way to use jTr with multiple cores and threads at
>> the same time to try crack one single password hash? How?
>>
>
> You just use OMP/fork as you'd do with multiple hashes. For OMP there are
> no quirks at all. For fork you might see that one process cracks the hash
> and the other processes doesn't get to know that - so they keep trying
> until manually killed. This will hopefully be addressed some time in the
> future.
>
>
Cool, I'm more interested in performance and stability, but it's cool to
know about this "bug" and it's nice as well to know it will be fixed soon.
:)


>
>  a) They clearly state that Radeon cards are much faster. My question is,
>> this information is still true recently?
>>
>
> Yes. For graphics or non-integer maths, nvidia might be as good or even
> better but for integers and bit shuffling (which is what we need), AMD
> always ran in circles around nvidia.
>
>
Great, I will take it into consideration.


>
>  b) I have heard that Radeons drivers sucks and are very unstable. Is that
>> true?
>>
>
> Unfortunately yes. Once you find a driver that doesn't show a bug nor a
> performance reduction in any format you need, hold on to it. Once you try
> an upgrade you need to test everything carefully. The built-in self-tests
> should catch most such problems so worst case is normally a known problem
> as opposed to false negatives (shrug) that you may experience with some of
> our competitors.
>
>
That looks like a real big problem. Just for the records, what GPU cards do
you have and what drivers work well at the moment?

What you mean by false negatives? jTr test a valid password and do not
report it as cracked?



>
>  c) What is JtR actual support for Radeon cards? At the moment and further
>> efforts are better Radeon or Nvidia?
>>
>
> JtR-jumbo is supposed to support *any* OpenCL device as long as you have
> proper drivers for it, even future ones without a rebuild/upgrade.
> Openwall's test rigs include AMD's, nvidias and an intel MIC.
>
>
Interesting. And what is the most mature at the moment with jTr? rings with
AMD's, nvidia or this new intel MIC?

As a developer, what do you think will be the focus for further development?



>
>  d) The infamous Radeon 6990 is not produced anymore and the used ones are
>> more expensive in comparison with 7970. LOL! There are newer models that
>> was unavailable at that time. What do you guys suggest? Should I buy 2
>> better GPUs? Or 3 GPUs that are average? Or one single super GPU?
>>
>
> Our multi-GPU support is not as mature as eg. Hashcats so a single fast
> GPU is currently better than two slower. I'd go for a R9 290X but its
> drivers are apparently very immature as of this writing. I expect that
> problem to go away soon with newer drivers.
>
>
By not mature what can I expect? Kernel panic? System shutdown abnormally?
jTr fails to work?

Are these R9 290X more powerful in comparison with 7970 or 6990? Do you
have any link for comparison related with password cracking? I would like
to compare prices vs efficiency and see what is better in my case :)


>
>  f) Finally, based on your suggestion of GPU card, what are the current
>> password hash formats supported?
>>
>
> Bleeding-jumbo branch supports the following using OpenCL (though some of
> them are much slower than HashCat):
> descrypt-opencl, ssha-opencl, nt-opencl, ntlmv2-opencl,
> agilekeychain-opencl, bcrypt-opencl, blockchain-opencl,
> md5crypt-opencl, sha256crypt-opencl, sha512crypt-opencl, dmg-opencl,
> encfs-opencl, gpg-opencl, keychain-opencl, keyring-opencl,
> krb5pa-md5-opencl, krb5pa-sha1-opencl, mscash2-opencl,
> mysql-sha1-opencl, ODF-opencl, ODF-AES-opencl, office2007-opencl,
> office2010-opencl, office2013-opencl, phpass-opencl, pwsafe-opencl,
> rar-opencl, Raw-MD4-opencl, Raw-MD5-opencl, Raw-SHA1-opencl,
> Raw-SHA256-opencl, Raw-SHA512-opencl, Raw-SHA512-ng-opencl,
> strip-opencl, sxc-opencl, wpapsk-opencl, XSHA512-opencl,
> XSHA512-ng-opencl, PBKDF2-HMAC-SHA256-opencl, RAKP-opencl
>
>
Some password hashes that I need to crack most of the time (netntlmv2,
mysql and mssql) do not appear to be included. Very sad :(

Do you know how often new formats are included? Is this a priority for
developers? Or GPUs is not very important at the moment for developers?


>
>  4) Once using GPU for cracking with jTr is it possible to use with
>> incremental mode?
>>
> >
> > 5) Once using GPU for cracking with jTr is it possible to use with
> > markov mode?
>
> All cracking modes are supported but for very fast hashes it's not as fast
> as it could be. Sometimes it's in the order of 100x slower than oclHashcat.
> Fixing that is WIP but currently that work seem to have stalled completely.
>
>
100x slower than oclHashcat. Wow, I'm surprised. Just for curious, what is
the reason?

My impression is that jTr is putting more efforts on CPUs and not GPUs and
I'm thinking if pays off invest some money on GPU on this case...


>
>  6) Suppose that I have a wordlist of almost 70GB. In this case the memory
>> of motherboard and memory of graphical card will influence a lot or not?
>>
>
> Host memory is cheap so you should have a lot, I'd say at least 16GB. GPU
> memory is not that important right now. As long as you have a couple GB
> you're fine, 16 GB is not needed for anything right now but it *may* be
> beneficial at some point in the future.



Cool, thanks for heads-up.


>
>
>  7) Does it worth to use two GPU cards together? Should they be connected
>> via crossfire? Or not? Is there any specific advantage for password
>> cracking with jTr?
>>
>
> Crossfire/SLI are for producing video. JtR can use multiple devices
> regardless. If your OpenCL driver serves us one or several cards, we can
> use them.
>
>
>
I was thinking that GPUs connected via crossfire could be used as a
"single" / "unified" card and increase the processing power.



>  8) Finally, I'm very concerned about power supply and cooler. What do you
>> guys recommend for a safe setup to keep this box running for week without
>> temperature issues? :)
>>
>
> The GPU should blow its heat *outside* the case like the reference designs
> do. For some reason many of the hip OEM models with lots of bells and
> whistles doesn't. These are badly designed toys IMHO.
>
>
Yeah, that's one of the things that I'm worried about. Do you know any
website with benchmarks about cases that could be useful to select one? :)


>
>  a) Should I consider a watercooler for my processor?
>>
>
> I think not. As Gosney put it, "when it fails, it fails spectacularly"...
>
>
I'm scared now. So the solution should be the old and ugly air cooler? :)

Thanks a lot.


> magnum
>
>

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.