[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
