[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20131121083751.GA587@openwall.com>
Date: Thu, 21 Nov 2013 12:37:51 +0400
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: Questions and suggestions to build a home cracking box. :)
On Wed, Nov 20, 2013 at 08:24:26AM -0600, Richard Miles wrote:
> 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?
I've listed relevant GPU types and AMD Catalyst driver versions in
another posting. We have other GPU types for our testing as well (some
NVIDIA, some mid-range, low-end, older AMD), but we do not recommend you
to buy those. Your choice is essentially between 7970/7950 and R9 290X.
> What you mean by false negatives? jTr test a valid password and do not
> report it as cracked?
Yes, that's what magnum meant by a false negative, however his point was
that running into this due to driver bugs is relatively rare with JtR,
because JtR performs a self-test (of the target format) when it starts.
magnum wrote:
> > 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?
NVIDIA is most stable (due to drivers), AMD is fastest. MIC is neither
(except at bcrypt). Also, MIC is beyond your budget (the cheapest I've
seen is $1200 for engineering samples on eBay).
> As a developer, what do you think will be the focus for further development?
The OpenCL kernels will be (attempted to be) portable to all devices,
although when compilers/drivers are too buggy in certain ways we might
not spend a lot of time on workarounds. Also, we're unlikely to spend
getting more of our OpenCL kernels to work (at all, let alone well) on
Intel MIC, due to the current state of OpenCL support there (Intel's,
not ours). Instead, we're likely to support a handful of formats
(likely descrypt and bcrypt) on Intel MIC with C+OpenMP+intrinsics,
which provides much better performance than OpenCL on this platform.
> > 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?
None of this, just having to use "--fork=2 --device=0,1" and such, and
accepting the usability drawbacks this involves (e.g., one of the two
processes might terminate much sooner than the other, especially if your
GPUs are not same type/speed).
> Are these R9 290X more powerful in comparison with 7970 or 6990?
Yes, more powerful than 7970. As to 6990, this may vary by hash type.
Overall, I'd expect R9 290X to be faster than 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 :)
R9 290X is meant to be 37% faster than 7970 GE (with both at 1 GHz).
It's almost the same architecture, so is directly comparable.
> 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?
It's not exactly that. We've been focusing on slow hashes; those hash
types you list are fast ones (that shouldn't have been used in the first
place, yet unfortunately are relevant...) To support them efficiently,
we need on-GPU password generation. As I mentioned in another message,
it exists in limited form (for mask mode only) in the bleeding-mask
branch. Ideally, we'd merge bleeding-mask into our main development
branch (perhaps after making a release without the bleeding-mask
functionality first), and only then would it make sense to proceed to
add more fast hashes on GPU. Right now, more fast hash types on GPU
would be useless from a practical standpoint.
> > 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?
magnum meant what happens with fast saltless hashes, outside of
bleeding-mask. When the host CPU generates candidate passwords and
hands them over to GPUs for hashing, this introduces a bottleneck at
under 100M candidate passwords/second - and thus under 100M hashes
computed per second, if we're talking saltless hashes. For some hash
types, high-end GPUs are actually capable of computing several billion
hashes per second. So they're left mostly idling, waiting for data.
With very fast hashes, JtR is actually faster on CPU alone than it is on
CPU+GPU. The "100x slower" above can thus be reduced to a smaller
factor (yet still embarrassingly large) by not using GPU in such cases
(using CPU with --fork instead).
This problem does not occur with slow hashes, where going from CPU to
GPU can change the speed e.g. from 5k c/s to 100k c/s (for mscash2),
similarly both with hashcat and with JtR.
> I was thinking that GPUs connected via crossfire could be used as a
> "single" / "unified" card
No. For OpenCL, they remain separate. Even two GPUs on a dual-GPU card
are seen as two separate devices.
> and increase the processing power.
Yes.
> So the solution should be the old and ugly air cooler? :)
There are some new and not so ugly CPU coolers. Pick one with a larger
fan (120+ mm), preferably placed on a side of the heatsink and blowing
from front to rear of your case (you need a sufficiently wide case since
these coolers are pretty big) - like one seen on the pictures here
(sitting on top of a 4770K CPU, although this cooler is overkill for
that non-overclocked CPU):
http://openwall.info/wiki/internal/xeon_phi#An-attempt-at-cooling-it
BTW, we ended up moving the Xeon Phi to another machine, since that
desktop'ish motherboard couldn't support it. (We need to update this
wiki page.) Here's its actual machine:
http://openwall.info/wiki/HPC/Village
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.
