Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Mon, 21 Jan 2013 01:02:16 +0100
From: Frank Dittrich <frank_dittrich@...mail.com>
To: john-dev@...ts.openwall.com
Subject: Re: binary_hash_[0-6] and get_hash_[0-6]

On 01/21/2013 12:25 AM, magnum wrote:
> On 20 Jan, 2013, at 20:16 , Frank Dittrich <frank_dittrich@...mail.com> wrote:
> I think you got false negatives too. This is the pkzip format (but I recall having seen others using NULL, at least a while ago):
> 
> 	{
> 		binary_hash0,
> 		NULL,
> 		NULL,
> 		NULL,
> 		NULL
> 	},

I just didn't think of formats adding NULL there.
This should find these cases (plus some false positives):

$ grep -C 1 "^\s*NULL,*\s*$" *_fmt*.c|less

Or just

$ grep -A 3 "_hash_3,*\s*$" *_fmt*.c|less

c3_fmt.c uses binary_hash_[0-4], NULL, NULL and get_hash_[0-4], NULL, NULL.
Looking at the definition of those hash functions, I am sure I won't
touch that code.

AFS uses 0-2, NULL, NULL, NULL
pkzip: 0, NULL, NULL, NULL

Is it really necessary (or a good idea) to add NULL pointers for
functions which are not implemented?
I think it just makes grepping for formats which don't implement all
hash functions up to _6 harder.

> BTW I have absolutely no idea what is going on with the pkzip format. It has a binary_hash0() that always returns 1 and a get_hash0() that returns something that look like Dhiru's crack arrays, and anyway the BINARY_SIZE is 0. ┬┐Que? I suppose we better not touch that!

May be I'll at least rename binary_hash0 to binary_hash_0 and get_hash0
to get_hash_0, to increase similarity between formats.

BTW: I found the reason for the difference between number of
binary_hash_6 and get_hash_6 functions in format structures.
LM_fmt.c is using binary_hash_6 and DES_bs_get_hash_6.

Frank

Powered by blists - more mailing lists

Your e-mail address:

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