Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
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

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ