Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 24 Jul 2012 00:54:26 +0200
From: Frank Dittrich <frank_dittrich@...mail.com>
To: john-dev@...ts.openwall.com
Subject: Re: mscash2 / hmac-md5 ambiguity

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.
Usually, I want to try an attack on the fastest saltless hashes first,
then proceed to slower salted hashes...
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...

Frank

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ