[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAFMma9MSdTjjpfdgTXQbvZeRfYy=E=XhRtGH-dZMhVA=gOWFHg@mail.gmail.com>
Date: Fri, 22 Nov 2013 12:47:45 -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 Solar Designer and guys,
I promise, this is my last e-mail today! I know you all will enjoy I stop
for a while with tons of e-mails :)
On Thu, Nov 21, 2013 at 2:37 AM, Solar Designer <solar@...nwall.com> wrote:
> On Wed, Nov 20, 2013 at 08:24:26AM -0600, Richard Miles wrote:
> > 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.
>
>
Interesting, based on Magnum message I was thinking that I should do it
myself every time that I upgraded or downgraded a driver. Is safe this
self-test done by JtR? Or do we have cases where it missed a valid
password? I'm just curious if I should double check, you know, this
password may be the one that you need / want :)
> 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).
>
>
Yeahh, very expensive. I would consider it only if it was a real BEAST and
working perfectly with all modes and formats. Let me keep with Radeon :)
> > 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.
>
Got it.
> > 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.
>
>
R9 209X should be 37% faster than ONE 7970 GE, right? If yes, based on
price, current driver stability and cooling issues I guess that 2 7970 GE
will be better, faster, safer and almost the same price. Do you agree?
> > 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...)
Yeahh, but in practice they are the most commons, at least on my customers
:)
> 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.
>
Got it. But should I expect to see on-GPU support for fast hashes when
using incremental and markov? :)
>
> > > 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).
>
Yeahh, my current approach will be CPU with fork. But I hope to be able to
use my GPU during the future :)
> > 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)
Cool, I did my home work and looked for several of options, I wrote about
them above. I hope you can advise since you are a master. :)
> - 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
WOW! This is insane!
>
>
> 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
Very cool, I was not aware of it, great project, congrats!
Best regards and thanks again.
>
>
> 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.
