Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 07 Jan 2014 11:14:49 +0100
From: magnum <>
Subject: Re: dynamic_2000 - dynamic_2014

On 2014-01-07 09:43, Frank Dittrich wrote:
> On 01/02/2014 02:52 PM, wrote:
>> ---- Frank Dittrich <> wrote:
>>> On 01/02/2014 01:55 PM, 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


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.