[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ebb5f5e66be97e2d1ee7b294db25e51a@smtp.hushmail.com>
Date: Wed, 20 Nov 2013 20:52:33 +0100
From: magnum <john.magnum@...hmail.com>
To: john-users@...ts.openwall.com
Subject: Re: Questions and suggestions to build a home cracking
box. :)
On 2013-11-20 15:24, Richard Miles wrote:
> On Wed, Nov 20, 2013 at 2:07 AM, magnum <john.magnum@...hmail.com>
> wrote:
>>> 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. :)
As far as I'm aware, fork, OMP and MPI are all stable. BTW everything I
say is with the bleeding-jumbo GitHub branch in mind, I can't even
recall what the latest "released" code could or could not do. You can
always get the latest snapshot as a tarball from
https://github.com/magnumripper/JohnTheRipper/tarball/bleeding-jumbo
> 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.
>>> 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 :-/
> 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.
>> 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.
>> 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.
> 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 :)
Rumors has it that R9 290X may outrun 6990 despite the latter being a
double-GPU card. In any case it will get near. I'd personally not buy a
used card so the arbiter is that 6990 and [reference design] 7970 is
not for sale anymore.
> 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).
> 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 :-)
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...
>> 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.
>> 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.
>>> 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!?
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.
