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
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.