[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAFMma9POjHQKQN-Z8=0UNUq_RHGBA6OPoQjiAkuKQS3TdUWsFQ@mail.gmail.com>
Date: Fri, 22 Nov 2013 08:17:01 -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,
Thanks so much for your answers, very appreciated.
On Wed, Nov 20, 2013 at 1:52 PM, magnum <john.magnum@...hmail.com> wrote:
> On 2013-11-20 15:24, Richard Miles wrote:
>
>> On Wed, Nov 20, 2013 at 2:07 AM, magnum <john.magnum@...hmail.com>
>> wrote:
>>
>>>
>>>>
>>>> Between OMP and Fork what is faster? Both support all password hashes
>> available on your github
>> (https://github.com/magnumripper/JohnTheRipper)?
>>
>
> For slow formats they are about the same speed. OMP is supported
> per format but most formats support it. The very fastest formats (eg.
> NT) does not support it, or support it with lousy scaling. Fork/MPI is
> on a lower level so every format can run under them and it scales almost
> linearly in many modes. MPI is (sort of) just like fork but can span
> multiple hosts over a network. A session started with --fork can be
> resumed under MPI instead, and vice versa.
>
> Like I said, OMP does not have the quirks. Also, using OMP you can stop
> a session and resume it with more/less cores than before while using
> fork/MPI you are stuck at the number of processes you had when you
> started it.
Thanks for explanation. In my case I guess that For is what I need, in
special because it works with one single hash and multiple cores / threads,
also works with all formats - most of my hahses are fast hashes. The only
downside are the quirks of kill process by hand and unable to stop and
restore sessions with different numbers of cores. Do you think these kind
of improvements will be available soon for Fork? I mean, is someone working
on it?
I guess this could be one of the nice things to include on Google Summer
Code if you guys consider it interesting enough. :)
>
> 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?
>>
>
> This problem is shared with all our competitors though: For
> reports/rumors/tests of drivers, the Hashcat forum is a good place
> to lurk in. It's not that bad, one gets used to upgrade and downgrade
> drivers :-/
Interesting. I have visited the hashcat forum and there are a lot of
information, but some people is far away to be friendly there. :)
In special the R9 290X appear to have tons of issues with drivers and
decent benchmarks.
>
>
> What you mean by false negatives? jTr test a valid password and do
>> not report it as cracked?
>>
>
> Exactly. That is the worst possible bug you can encounter. Even worse
> if you never become aware of it but like I said our self-tests are
> likely to catch it in time.
Yeah, very severe bug. What do you mean by self-tests? Just run the
benchmark? Or create a copy of password hashes that I know the plain-text
passwords and always test with them before and after upgrade / downgrade a
driver?
>
>
> 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 drivers generally has less bugs but like I said nvidia perform
> like crap compared to AMD. AMD is usable, don't get me wrong. It's just
> that you may encounter driver versions that are crap so you need to
> upgrade or downgrade the driver.
If a driver upgrade or download solve the problem it's OK, the main problem
in my opinion is instability with all drivers. :)
>
>
> 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?
>>
>
> Except for one single format (mscash2) you currently need to use --fork
> to run with multiple GPU devices. With fork comes that problem I
> mentioned where one process might crack it and the other ones continue
> trying. Nothing worse.
I understood. But based on Solar Designer's answer it may be because the
load of passwords were not balanced exactly correct or one card is faster
in comparison with other, correct?
In resume, both will finish automatically, correct? Or should I kill them?
>
>
> Some password hashes that I need to crack most of the time
>> (netntlmv2, mysql and mssql) do not appear to be included. Very sad
>> :(
>>
>
> NTLMv2 is there, it just isn't prefixed with "net". MySQL and MSSQL
> could be implemented in no time but it's no much use until we fix the
> speed issues with faster hashes (it's a core issue and not a format
> issue, see below).
>
>
I got it, hierarchical problem.
>
> 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?
>>
>
> We lack developers. I write a format now and then and I prefer writing
> GPU ones. On average, Dhiru writes about a format a week, often both
> for CPU and GPU :-)
>
>
I believe, and I can't help, the best I'm able to do is shell script. I'm
ashamed :P
> Me and Claudio are currently "wasting time" with shared OpenCL code that
> isn't very noticable for end users. In the long run it's supposed to
> result in less work so we can just write more formats...
Interesting. Is it related with the issues that we have today with GPU and
fast hashes?
>
> 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?
>>
>
> OclHashcat generates password candidates on GPU. JtR currently generates
> them on CPU and sends them over the PCI bus which can become a huge
> bottleneck. For slow formats like WPAPSK or new MS KRB5 it doesn't
> matter (we're on par with Hashcat with several formats) but for fast
> formats like MSSQL it matters a lot.
So this GPU cards are so fast that they are able to computate hashes before
a CPU is able to choose one? I guess we are talking about --incremental and
--markov mode, right?
The same problem should happen with wordlist attacks, right? Or maybe with
wordlists and fast hashes it's still worst! I mean, HD should be very slow
and create a bttleneck, right? Even with --rules? The --rules pre-processor
works with CPU or GPU?
>
> 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? :)
>>
>
> The hardware subforum of Hashcat forums (hashcat.net) is a good place.
> Same needs, same heat problems, same driver problems.
Cool, I will keep my eyes opened. :)
BTW, Solar Designer gave me good ideas and explanation about my hardware. :)
>
>
> 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? :)
>>
>
> With proper standard components you wont have any problems with CPU
> heat, you can even have a pretty quiet rig. GPU heat is a bit harder but
> in general I don't see heat as a big problem. Just don't buy a toy card
> that emits the heat inside the case. What the hell are they thinking
> designing these!?
I heard that i7-4930K gets really hot and for intensive password cracking
it could be an issue. I will keep my eyes opened.
How to identify if a GPU emits air inside the case and the good ones? I
should always choose a reference designer? But how to discover what is a
reference designer without ask you guys? :)
I also heard that GPU with reference designer are loud. Is that true? I
mean, this box will be on my side during the whole day :)
Thanks.
>
>
> 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.
