Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 30 Mar 2015 03:02:08 +0300
From: Alexander Cherepanov <ch3root@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: Lengths of fields recorded in hashes

On 2015-03-23 04:37, 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.

Well, Ok. Maybe it's not that hard to support lengths after all. Perhaps 
we can return to this question later.

>> 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.

Is there a list of john formats supported by Hashcat?

> I think it may be best (in general) to just keep these formats as-is and
> do a better job with future formats.

Ok, but do we understand what we want to keep? Take for example 7z 
format. All test hashes look like this:

$7z$0$19$0$1122$8$d1f50227759415890000000000000000$1412385885$112$112$5e5b8...
          ^1^^^^2^3^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^4

The part 1 above ($0$) is supposed to be the length of salt -- the part 
2 ($1122$) -- and the part 3 ($8$) is supposed to be the length of iv -- 
the part 4 ($d1f50227759415890000000000000000$). Both are bogus. Right 
now, the salt and its length are just both ignored and there is some 
hack for iv which probably works only for iv lengths <= 8.

-- 
Alexander Cherepanov

Powered by blists - more mailing lists

Your e-mail address:

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