Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 21 Jan 2013 00:25:51 +0100
From: magnum <>
Subject: Re: binary_hash_[0-6] and get_hash_[0-6]

On 20 Jan, 2013, at 20:16 , Frank Dittrich <> wrote:
> Looks like I got false positives here.
> I also found these in DES_fmt.c, BSDI_fmt.c and opencl_DES_fmt.c.
> #define get_hash_0 DES_bs_get_hash_0
> #define get_hash_1 DES_bs_get_hash_1
> #define get_hash_2 DES_bs_get_hash_2
> #define get_hash_3 DES_bs_get_hash_3
> #define get_hash_4 DES_bs_get_hash_4
> #define get_hash_5 DES_bs_get_hash_5
> #define get_hash_6 DES_bs_get_hash_6
> $ grep "^\s*binary_hash_[0-6]\s*$" *_fmt*.c|sed
> 's#^.*\(.\)$#\1#'|sort|uniq -c
>     16 4
>    102 6
> $ grep "^\s*get_hash_[0-6]\s*$" *_fmt*.c|sed 's#^.*\(.\)$#\1#'|sort|uniq -c
>     16 4
>    101 6
> I'll look at the 16 formats implementing only *_hash_[0-4], and check
> where the one difference for *_hash_6 comes from.

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):


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!


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.