[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20200508180343.GA21006@openwall.com>
Date: Fri, 8 May 2020 20:03:43 +0200
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: Hashes with different formats in Johnny
Hi MA40,
On Fri, May 08, 2020 at 06:22:31PM +0200, MA40 wrote:
> Using Johnny, when all the hashes are the same format there is no problem.
>
> My question is whether an attack can be carried out with several hashes at
> the same time, but these hashes are of a different format, for example, one
> is MD5, the other is SHA-256, etc. I do not succeed. Is this attack
> possible?
Generally, no. And this is not specific to Johnny, but is how John
works. One John session can only load hashes that are recognized as one
"format". In some special cases, a format may recognize what you'd
possibly consider more than one hash type. In fact, in your very first
posting in here you inquired about two variations of Bitcoin wallet
"hashes", where we support both in the same "format" and could thus load
both variations simultaneously. Another such example are FreeBSD-style
md5crypt, Apache apr1, and AIX smd5 hashes, which are similar enough we
treat them as one "format", even though they look differently and their
computation is also slightly different. There are many more examples
like this, but in general they are exceptions and not the rule. Your
example with MD5 and SHA-256 isn't one of those exceptions, so you have
to run two separate John sessions on those hashes.
The good news for you is that often you actually maximize efficiency by
running separate attacks on different hash types. That's the case when
the different hash types are of very different speed. If you attack
such hashes simultaneously (if this were supported), then you'd test
unnecessarily few candidate passwords against the faster hashes, because
the attack's speed would be limited by the slower hashes. Another way
to look at this is that the faster hashes wouldn't get what you'd likely
consider their fair share of processing time.
For example, if one hash is 99 times faster than the other, it will only
receive 1/100th of the processing time when you test a certain number of
candidate passwords against both hashes at once. This makes that number
unnecessarily low for the faster hash. With an equal split of
processing time, such as what you can achieve by running separate
attacks, you'd test 50 times more candidate passwords against the faster
hash, but only under 2 times fewer of them against the slower hash.
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.
