Date: Mon, 23 Mar 2015 02:21:27 +0300 From: Alexander Cherepanov <ch3root@...nwall.com> To: john-dev@...ts.openwall.com Subject: Lengths of fields recorded in hashes Hi! 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. Does anybody consider them useful? They could potentially be useful when one needs to allocate memory for the data but even in this case they save only one strlen (or equivalent). OTOH each superfluous field now requires several lines of code in valid() and get_salt(). And parsing numbers is not that easy, e.g. atoi exhibits undefined behavior on overflows. Extra fields also take extra space etc. Recently the point was raised that lengths are an obstacle to fuzzing. And it would be nice if most of the hashes are constructed from a small number of simple blocks (a field containing a length of another field is not one of them). I propose the following plan: 1) gradually rewrite valid()s and get_salt()s to ignore lengths recorded in hashes; 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)? 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.) WDYT? -- Alexander Cherepanov View attachment "0001-7z-compute-data-lengths-from-data-fields-in-hash-and.patch" of type "text/x-patch" (3119 bytes)
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.