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 04:36:26 +0200
From: magnum <>
Subject: Re: Lengths of fields recorded in hashes

On 2015-03-30 02:02, Alexander Cherepanov wrote:
> On 2015-03-23 04:37, magnum wrote:
>> 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?

Not exactly, but is a
good place to see Hashcat syntax.

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

Ignored fields are a nuisance. Ideally we'd need to strip them from the
canonical represenation used in the pot file. Otherwise another "same"
hash with different content in ignored fields are not seen as equvialent.

And I really think we should reject those hashes. A length field shall
match the actual length.


Powered by blists - more mailing lists

Your e-mail address:

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