[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200527204447.GA25165@openwall.com>
Date: Wed, 27 May 2020 22:44:47 +0200
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: hashcat vs. JtR
On Tue, May 26, 2020 at 05:36:24PM +0200, Solar Designer wrote:
> A reporter contacted me privately asking:
>
> "In 2020, how would you judge the main differences between hashcat and
> JtR, and for which use cases?"
>
> and clarifying:
>
> "For my purposes a high-level understanding of the differences would be
> most useful"
>
> I suggested to post my thoughts on this publicly so that others can see
> and comment (and maybe correct me).
Due to some off-list discussions, I came to realize that my idea to
handle this on john-users wasn't all that great after all, as it's
biased to participation by those who use JtR and excludes participation
by those who use only hashcat. So far, we only have comments by people
who use both, yet some of them (me included) may be more frequent JtR
users than hashcat users. There's also bias by communication medium of
choice - old-fashioned mailing list for JtR vs. modern web forum for
hashcat - which might correlate with preference for an older vs. younger
tool accordingly. Thus, this thread should be taken as commentary by
the JtR community rather than a neutral comparison.
This also made me arrive at another aspect I had missed: part of the
reason why someone chooses to use primarily one tool or the other might
have to do with being comfortable or not with the communication
platforms of choice (forum vs. mailing list). The only official channel
for free support on JtR is currently this mailing list. We often have
people uncomfortable with mailing lists ask for support on GitHub, but
that's not how we currently use GitHub issues (we use them to track
issues in the program), so we direct those people to the mailing list.
Some people do join the mailing list, some don't. So we lose some
prospective users right there. Maybe our approach should change. In
contrast, modern Internet users like this are probably more comfortable
with hashcat forums and find a welcoming community there.
Also, I went to re-check a few things regarding hashcat since yesterday,
and now have some corrections:
> JtR is usually faster than hashcat on CPU (especially for slow hashes
> like bcrypt), but hashcat is usually faster than JtR on GPU (especially
> for fast hashes like NTLM). There are occasional exceptions to that.
> For example, hashcat's NTLM is impressively fast even on CPU (with
> Intel's OpenCL), while JtR's optimized md5crypt is twice faster than
> hashcat's on NVIDIA Kepler GPUs (which hashcat considers too old and
> unsupported, but in practice is able to use anyway).
hashcat's performance on CPU with Intel's OpenCL is better than JtR's
for many fast hashes, not only for isolated examples like NTLM. More
specifically, in my testing on CPU hashcat tends to outperform JtR at
hashes faster than raw SHA-512, but is slower than JtR at hashes slower
than raw SHA-512, with raw SHA-512 being roughly the break-even point.
Like with most generalizations, there are exceptions to that (e.g., JtR
is faster at LM hashes, even though they're faster than raw SHA-512), as
well as variations by other parameters (number of hashes, etc.)
Also relevant here is that JtR can only reach decent speeds at fast
hashes on multiple CPU cores through use of multiple child processes
requested with "--fork", which is cumbersome. Its cleaner alternative
is OpenMP (which modern C compilers support natively, so it isn't a
nuisance to get working), but it's only efficient for slower hashes.
(This issue isn't inherent to OpenMP, but is a result of the simpler way
in which we use OpenMP currently, with candidate password generators
staying out of OpenMP parallel regions. hashcat avoids a similar issue
by having candidate password generators implemented partially in OpenCL
rather than only in "host code".)
While testing hashcat performance on CPU for the above comparison, I was
reminded of a usability difference: JtR autodetects (non-)hash types
(and suggests named alternatives when a hash encoding is ambiguous),
whereas with hashcat one has to remember or look up a mode number in its
lengthy "--help" output.
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.
