[<prev] [next>] [day] [month] [year] [list]
Date: Tue, 7 Jan 2014 09:06:25 -0600
From: "jfoug" <jfoug@....net>
To: <john-dev@...ts.openwall.com>
Subject: RE: dynamic_2000 - dynamic_2014
-----Original Message-----
On 1/7/2014 4:15 magnum wrote
> I think it should simply be one single but *configurable* tag. If nothing is configured, dynamic_1000 will have $dynamic_1000$ but if it's configured as $foo$, that and only that tag is valid, and is written to pot. Constraint on configured tag is that it start and ends with $
>
> On a related note I've had thoughts about core *) functionality for tag aliasing. A list of tags will be accepted, but converted to a canonical tag at loader stage with no particular support from the format. The canonical (the format's) tag will be written to pot so in that end no logic is needed.
All this is nice, but somewhat short sighted. Dyna is a tough nut, when it comes to valid (and other parsing functions like salt, prepare, etc). There is very little to parse, and 'know' will be there. There are many additional items with the hash, many optional, some not, sometimes salted, sometimes not, sometimes user id, etc, etc, etc. Simply listing some form of valid 'tag', may work for the most simplistic formats, but is far from idea.
> Speaking of that I've also considered some kind of format name aliasing.
> That way when we change the name of a format, the old name can still be used. It will be converted during options parsing, so format will know nothing about it. You would love writing bash completion for that %-)
>
> Both these will have their lists in john.conf.
>
> *) Core as in formats.c and loader.c, not core tree
I know you guys have been working hard on unification, and trying to normalize all of the non-coordinated work done by many authors over the years. I do not have a lot of answers here, but I worry that a lot of time chasing tails is being done. I am wondering if it is at the point where a 'true' format manager is needed, vs trying to keep this sort of logic all scattered throughout 100s of independent format files. This is not a trivial undertaking, and I think trying to do this piecemeal will never end up being right, nor end up ever being completed.
I think it is an ideal idea, but like magnum mentioned, does it really crack any passwords faster? Isn't that the crux of what JtR is in totality, a versatile command line 'unix' password guessing engine? Would this be better done in a 'wrapper' environment? NOTE, I do not have answers for any of these questions, simply posting them.
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.
