[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <04d901cf0bb3$d6133bf0$8239b3d0$@net>
Date: Tue, 7 Jan 2014 08:22:03 -0600
From: "jfoug" <jfoug@....net>
To: <john-dev@...ts.openwall.com>
Subject: RE: dynamic_2000 - dynamic_2014
On 1/7/2014 2:44: Frank Dittrich wrote
>It doesn't have to stop at accepting the hashes of other dynamic formats.
>
>Format dynamic_33 could also accept $NT$ hashes.
This is very hard here. In this case, we almost need to have an array of function pointers. I CERTAINLY am not going to replicate a bunch of valid() methods from other formats. Wow, that is a bad idea. Also, since we use static functions (and are not using C++), getting the function pointer(s) for doing this, is almost impossible. Well, they are contained within the format objects, but since we do not publicly define them (they are simply publicly defined in john.c, so they 'are' available), it makes using them tough, ALONG with, it adds a lot of dependancies between the source modules. We already have some of that in loader and others.
I do like the idea, I simply feel this is something that is NOT going to happen. The only way I could see something like this, was if
>In this case, it might even be good if dynamic_33 would use $NT$ as the default prefix.
>Also, all the implementations (dynamic_33, nt, nt2) support the same max. password length of 27.
Again, great idea, but unless this becomes a hell of a lot less ugly than I suspect, I would argue against it, strongly.
> At least accepting $NT$ as valid would be an improvement.
>
> Instead of dynamic_33 using an $NT$ prefix as the canonical representation, nt and nt2 could also use $dynamic_33$ as a prefix, since dynamic_33 is implemented in C, and not defined in a config file.
>But my personal preference would be to use $NT$.
This 'one off', certainly is easy to 'hack' in there. But what happens next time, and next time, and next time??? Already dyna is a nightmare format. Right now, there are about 6 to 10 duplicated formats, where we have a fat format, and dyna. Also, we have 'thin' formats, where dyna is used internally, but there is a specific format. makin dyna and $NT$ work together is a nice idea (really nice), but it is only a very tiny part of the whole problem. The problem really should not be 'solved' one off at a time.
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.
