[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 07 Jan 2014 11:14:49 +0100
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: dynamic_2000 - dynamic_2014
On 2014-01-07 09:43, Frank Dittrich wrote:
> On 01/02/2014 02:52 PM, jfoug@....net wrote:
>>
>> ---- Frank Dittrich <frank_dittrich@...mail.com> wrote:
>>> On 01/02/2014 01:55 PM, jfoug@....net wrote:
>>>> There are some caveats here (there always are).
>>>
>>> We could make dynamic_2002 accept dynamic_2 and dynamic_2002, but use
>>> dynamic_2 as the canonical representation (which gets written to .pot
>>> files).
>>
>> That would not be a bad way to go. Split it up, giving 3 configuration values.
>>
>> 1. the actual dyna number for the format.
>> 2. an 'optional' array of dyna numbers which also can be processed by this format.
>> 3. the canonical number (i.e. number that gets written to the .pot file).
>
> It doesn't have to stop at accepting the hashes of other dynamic formats.
>
> Format dynamic_33 could also accept $NT$ hashes.
> Currently, it only recognizes the plain hex hashes without any prefix.
> But NT hashes and dynamic_33 hashes only differ in their prefix.
>
> 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.
>
> 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$.
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.
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
magnum
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.
