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.