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.