[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5011C74A.1030802@mccme.ru>
Date: Fri, 27 Jul 2012 02:40:10 +0400
From: Alexander Cherepanov <cherepan@...me.ru>
To: john-dev@...ts.openwall.com
Subject: Re: mscash2 / hmac-md5 ambiguity
On 2012-07-24 02:54, Frank Dittrich wrote:
> On 07/23/2012 11:19 PM, Alexander Cherepanov wrote:
>> On a more practical note, this means that you cannot build a robust
>> system to run john for different kinds of hashes without --format. In a
>> contest we get some hashes, determine their format and sort them into
>> files named after formats. For me that's enough -- with it I can do
>> things like that:
>>
>> for file in *.john; do
>> format=`basename "$file" .john`
>> john ... --format="$format" "$format.john"
>> done
>
> It is a little more complicated.
Thanks for your very informative (as always:-) reply.
> Usually, I want to try an attack on the fastest saltless hashes first,
> then proceed to slower salted hashes...
I'll try (tomorrow) to make some script which shows speed and weight
info for different kinds of hashed so that it's easy to see which are
fast and which are expensive.
> What is fast also depends on the attack.
> --single is fast on salted hashes, because you only have a few words per
> salt that get mangled, whereas for saltless hashes, each user name is
> mangled and the computed hash compared against each uncracked hash. So
> the sequence differs.
> Also: some hash formats have GPU support, some hashes don't.
> For GPU, --single mode is not the best mode with regard to c/s rate.
> Some formats have different implementations (raw-sha1-ng vs. raw-sha1)
> which differ in c/s rate, but have different max. password length.
> Some formats don't have OMP support, some do, but scale not very good,
> so you might prefer to run N instances (1 per core) at the same time,
> instead of 1 OMP instance with N threads (or N*2 with hyperthreading).
>
> Some attacks don't make sense for certain hash formats (toggling case
> for formats which are not case sensitive, or DES which just takes into
> account 7 bits per character (so no use in trying non-ascii characters)
> and is limited to length 8 (so usually not worth trying phrases of 3 or
> more words).
>
> Of course, you can adjust your attacks (rule definition to reject a rule
> unless a format is case sensitive...), but during a contest, you usually
> don't take the time to write perfectly fitting rules - in most cases
> just rules that seem to be "good enough".
>
> And if I have 4 cores available, I might want to make sure that all 4
> cores are busy all the time.
> So, if I can define attacks fast enough, it would be best if there was a
> way to automatically launch the next attack once a core is free -
> without me sitting in front of the monitor and switching tabs/screens to
> see which task has finished...
To keep track of how many johns are runnig probably it is enough to
print in a cycle something like this:
ps -A | grep -c john
of running top?
BTW how bad is to run several johns on one core simultaneously?
--
Alexander Cherepanov
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.
