Date: Mon, 23 Mar 2015 02:37:26 +0100 From: magnum <john.magnum@...hmail.com> To: john-dev@...ts.openwall.com Subject: Re: Lengths of fields recorded in hashes 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.