[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAF37FbU1OVfPfE_OQGV+ykB2k5hxx2TA7zG4V4Zo4zLTQicu=g@mail.gmail.com>
Date: Mon, 7 Dec 2015 06:37:13 +0100
From: atom <atom@...hcat.net>
To: john-users@...ts.openwall.com
Subject: Re: hashcat CPU vs. JtR
Back then when I started with Hashcat it was already clear that CPU based
cracking was about to get outdated by GPU. But since I was new to both,
GPGPU and crypto, I had to learn alot at once. That's simply more easy by
writing code for CPU. I did that with Hashcat CPU. That was a time when
there was only SSE2, no AVX and no XOP. Back then, hashcat was by far
faster than any other CPU cracker. When I had the feeling that I understood
the basic hashing algorithms I instantly started to write GPGPU code and
stopped working on hashcat CPU completely, with the result that what you
see today as "hashcat" is almost 4 year old code. The only thing I've added
was the XOP code and some algorithms.
For me it's oclHashcat that counts and which I've refactored completely
about 5 times till I found the architecture of today. In theory, a pure CPU
integration into oclHashcat would be easy. Just add a new Platform, write
the basic macros and for each hash-mode write a function that uses the same
parameters as the OpenCL kernels do and simply copy/paste the OpenCL kernel
code. I did that once, just to find out if it would work, to end up with an
NTLM BF speed of over >900MH/s on my i7-4770K. Such a speed on CPU is far
from what you see in JtR or mdxfind and it will work for any other
algorithm supported with oclHashcat. The question for me was do I really
want to put that effort to build support for a cracker that runs 25 times
slower than a 250€ GPU? Unless you have an explicit anti-GPU algorithm they
all will run much faster on GPU. So this question actually ends up in a
discussion CPU vs. GPU which I really do not want to start here.
I just wanted to point out that all the code in oclHashcat, the bitmaps,
the rule-engine, the vliw (or SIMD) support, the optimizations inside the
algorithms and whatnot else, compared to hashcat CPU is a difference of 4
years and 4 refactorizations. I'm really wondering why you even started to
compare. Maybe you don't know, but many people mean oclHashcat when they
talk about hashcat, it's just an alias. That's why my long-term plan is to
add CPU support to oclHashcat, then obsolete hashcat and then rename
oclHashcat into hashcat.
On Sun, Dec 6, 2015 at 10:27 PM, magnum <john.magnum@...hmail.com> wrote:
> On 2015-12-06 15:53, Solar Designer wrote:
>
>> On Sun, Dec 06, 2015 at 05:40:44PM +0300, Solar Designer wrote:
>>
>>> [solar@...er hashcat-build]$ ./hashcat-cli64.bin -b -m 3200
>>> Initializing hashcat v2.00 with 32 threads and 32mb segment-size...
>>>
>>> Device...........: Intel(R) Xeon(R) CPU E5-2670 0 @ 2.60GHz
>>> Instruction set..: x86_64
>>>
>>
>> Oh, I just realized I should have explicitly built for AVX. I just did,
>> with "make posixAVX". This produced hashcat-cliAVX.bin. Somehow it's a
>> bit slower at bcrypt:
>> (...)
>> So clearly AVX does improve speeds at some of these, but overall it's
>> the same picture as before.
>>
>
> Another aspect is HC does not take advantage of AVX2 yet and Atom had no
> plans for fixing that (but now someone else could). So using an AVX2 build,
> JtR runs in circles around HC. And we also support AVX-512 already...
>
> magnum
>
>
--
atom
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.
