[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140405100453.TVZR5.205960.imail@fed1rmwml108>
Date: Sat, 5 Apr 2014 10:04:53 -0400
From: <jfoug@....net>
To: "john-dev@...ts.openwall.com" <john-dev@...ts.openwall.com>
Subject: RFC on format alias coding
I would like to ask the dev community to think about what and how we could implement an alias module within JtR.
This (need) was talked about a bit offline between magnum and myself recently, in relationship to using different hashes (hash signatures), but same internal code. Examples would be:
phps, dyna_6, dyna_7 (has been removed, but here for this example), dyna_2006 magnum's dyan_1107 'test code', etc.
Each of those are of the same hashing algorithm, i.e. md5(md5($p).$s) So anything cracked with any of them is a valid crack of this type.
Now, what would be ideal, is that anything found with dyna_6 would be ignored by dyna_2006.
Places I can see where this would need to happen are: .pot removal at cracking load time. --show --show=left, and loading the original hashes out of the input file.
First request question, "Are there other places within JtR runtime where alias detection would be needed?"
The biggest question I have, is what would people implementation details be. I can think of things like this:
1. alias's would be handled in a stand alone file (possibly a .conf included by john.conf).
2. the alias engine would need to load all formats listed in this config file.
3. I believe that prepare()/valid() can be called prior to init, so the alias would not need to init the formats (hopefully).
4. at proper points within JtR coding (mostly loading, etc), calls would be made to the alias engine, to see if a hash matches one of the alias's for the currently being used format.
The above to me seems way to simplistic, but possibly that is all that we need to get this working. Unification of format signatures is another way (it is done already between phps and dyna_6). I guess this is also an option, but that assumes that we can unify them, AND it forces the users into using --format=forced_type more often, if 5 formats all share the same signature. If each kept it's own signature, but we had an alias module, albeit making more difficult for a user on one machine to share his input file which is based upon the fastest method for him, with another user/machine where a different format is fastest (i.e. CPU vs cuda vs opencl, or some other format).
Jim.
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.
