[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <f0fcffaa6aa605f71a5e23f829a0be3d@smtp.hushmail.com>
Date: Mon, 30 Mar 2015 04:47:28 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Lengths of fields recorded in hashes
On 2015-03-30 02:14, Alexander Cherepanov wrote:
> On 2015-03-23 05:40, Solar Designer wrote:
>> BTW, officially - such as in formats.h - this function is called
>> salt(). And ditto for binary(). The get_ prefix, as used by many
>> formats, isn't exactly right: these function aren't "getters" (from the
>> format's state), they are "extractors" (from the function argument).
>> Maybe we should rename them dropping the get_ prefix, or changing it to
>> extract_ (but that's longer, and ext_ would conflict with the naming
>> we're already using for functions implementing external mode support).
>> For now, let's not bother - not the worst of our worries, by far.
>
> Ok, I've added it into todo list:
>
> - Unify function names (get_salt -> salt etc.). This makes
> grepping/refactoring easier.
Contrary to this (and to Solar's suggestion) I unifed most salt() in
Jumbo formats to get_salt() a day ago or so. One reason is that core
john has them like that almost universally. Another is that unifying to
salt() resulted in lots of name clashes and need for ugly workarounds.
>>> 2) change the format of hashes in john and in 2john tools at some later
>>> point.
>>
>> Hmm, to be compatible with your changes proposed as step 1 above, would
>> the versions of *2john tools from step 2 produce empty fields in place
>> of the lengths? That is, two field separators in a row? That's still
>> not pretty.
>>
>> Anyway, we probably should do this, for the reasons magnum explained.
I think Solar meant to say "should not do" here, or the reference to me
would not make sense.
> You mean to accept empty length but check that it's right if it's not
> empty?
If there is a length field, we should reject it if it does not contain a
length that match the actual data. If we accept empty fields OR
filled-in correct fields, we end up with john.pot entries that look
different (eg. --show will not show them as cracked). So we end up
needing to unify to a canonical format in split(). More work, more code,
more bugs. Bad!
magnum
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.
