[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 23 Mar 2015 05:04:39 +0300
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: Lengths of fields recorded in hashes
I'm with magnum on the below. (One of the rare occasions where I find
top-posting appropriate, as I am commenting on magnum's message in its
entirety and it's too long to quote on top of my brief comment.)
It's a pity that those formats have redundant data in them, and we
should avoid this for future ones, but now that the existing ones do
have this data changing them isn't necessarily a good idea. And if we
keep them as-is, then valid() should be verifying the encoded lengths.
In general, valid() should verify as much as practical, and it's clearly
practical to verify the lengths.
On Mon, Mar 23, 2015 at 02:37:26AM +0100, magnum wrote:
> On 2015-03-23 00:21, Alexander Cherepanov wrote:
> > For some formats, hashes contain variable-length data (say, encoded in
> > hex) and the length of this data is also recorded in the hashes. One of
> > the examples is 7z format which contains 3 data field (salt, iv, data)
> > and 3 lengths for them.
> > I think their inclusion was an error and they should be removed. Mainly
> > because they are useless and only complicate things.
>
> I agree, except I may or may not agree they should be removed.
>
> > I propose the following plan:
> > 1) gradually rewrite valid()s and get_salt()s to ignore lengths recorded
> > in hashes;
>
> IMHO: As long as we accept the length field at all, valid() should
> verify that it matches actual data length. But binary() and salt() can
> just ignore it.
>
> > 2) change the format of hashes in john and in 2john tools at some later
> > point.
> >
> > Can we change format of such hashes at will (by requiring to always use
> > john and 2john tools of matching versions)?
>
> I recall we changed some OSX format and later found out the "Dave tool",
> or whatever it was called, outputs the old format. Also, lots of formats
> are added to Hashcat with same syntax as JtR. So before changing a
> format we must ensure we wont regret it.
>
> I think it may be best (in general) to just keep these formats as-is and
> do a better job with future formats.
>
> > Attached is a patch to 7z format which implements the first part of the
> > plan as an illustration of the approach. (It also fixes a potential
> > overflow in data field and removes strange dealing with zeroes in iv.)
>
> I think valid should reject hashes where a length field does not match
> length of data.
>
> 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.
