[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BLU0-SMTP164682017175C8990FFEA02FDB60@phx.gbl>
Date: Tue, 7 Jan 2014 11:27:16 +0100
From: Frank Dittrich <frank_dittrich@...mail.com>
To: john-dev@...ts.openwall.com
Subject: Accepting multiple format tags as valid (was: dynamic_2000 - dynamic_2014)
On 01/07/2014 11:14 AM, magnum wrote:
> On 2014-01-07 09:43, Frank Dittrich wrote:
>> 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 $
1. If we drop $dynamic_33$ as valid, then hashes stored in an older pot
file will be ignored, because these will use $dynamic_33$.
2. As long as this doesn't lead to a dynamic format grabbing hashes it
can't crack, I wouldn't use any restrictions regarding a possible prefix.
> 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.
Will you post your design ideas/decisions to john-dev first, or will we
find out once the change hits bleeding-jumbo?
Frank
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.
