Date: Wed, 23 Jan 2013 17:47:41 +0100 From: Frank Dittrich <frank_dittrich@...mail.com> To: john-dev@...ts.openwall.com Subject: FMT_MAIN_VERSION and formats structure changes (was: Min password length) On 01/23/2013 02:45 PM, jfoug@....net wrote: > I know for max length, we use PLAINTEXT_LENGTH, and put that into the plaintext_length section of the format, and then JtR will handle password lengths (truncating, I think). In most cases, this is just the max. length (in bytes) supported by John's implementation. It could well be that the application using this password hash mechanism has a maximum password length which differs from John's implementation. The question is whether this max. length is in bytes or in characters. (I know that for SAP the max. length of 8 or 40 (for CODVN F or I) is in characters, not bytes.) > What about formats which have a min password length? IMHO, if we add support for this, we should be able to handle (or at least report, if handling turns out to be too complicated) minimum and maximum length supported by the format itself (as it is used in real applications), not in John's implementation. There also needs to be an indicator whether the length is given in bytes or in characters. (Supporting longer passwords could mean a fallback to a slower implementation, or providing different implementations. But if we'll have even more implementations for a single format, magnum's suggestion to split --format and --implementation needs some thought. (Magnum just mentioned splitting, he didn't suggest a name. May be he doesn't like --implementation, because then you can't abbreviate --incremental just using -i.) Currently, there are up to 2 CPU implementations plus 2 GPU implementations for a single format. Doing this might even justify splitting the current formats structure into two parts - one of which could be reused by each implementation. Next question: For unstable, FMT_MAIN_VERSION is 9. For bleeding, it is 11. Is it acceptable to change the format structure without increasing the version number, as long as this changes is only in bleeding? (I am not sure where 10 or 11 have been used, except for bleeding. If there was a contest edition which used 11, it might not be a good idea to change the definition without adjusting FMT_MAIN_VERSION.) If we change the format structure again, we should discuss which other changes might be included at the same time. E.g., I'd like to see a reference to the source file which implements a certain format being included. That could be just an additional component __FILE__. Including this information into --list?=format-details and --list=format-all-details would it make a little easier to answer questions like "What should hashes for a certain format look like so that john is able to recognize them?" 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.