[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150509072633.GA29452@openwall.com>
Date: Sat, 9 May 2015 10:26:33 +0300
From: Aleksey Cherepanov <lyosha@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: get_binary_*() and get_hash_*() methods
Solar,
On Thu, May 07, 2015 at 05:39:45PM +0300, Solar Designer wrote:
> > Is the db intended to be checked by crypt_all()?
>
> For fast hashes and/or with delegation to another device (such as a
> GPU), it may be.
>
> You can see a dirty hack like this here:
>
> git show 9a6f4f6f69903763e664f03d2adee97486eca9de DES_bs_b.c
>
> This patch served to move the bitmap and hash table lookups into the
> same OpenMP parallel region that computes the hashes.
The patch may be improved in the following bit of code:
salt->index(index);
where salt->index is a pointer to one of get_hash_*() functions.
You may let compiler to inline the function. I guess that'll need a
top level switching between 7 variants of code by salt->hash_size.
Though it may bump code cache. Oh, it would be easier to use
DES_bs_get_hash(index, count) there.
Putting the code there allows to "transpose" cmp_all() to replace bit
masks, i.e. we make a function to check a result against the loaded
hashes that we store as bit vectors: there are packed bit vectors for
hashes and we traverse them comparing with bits. Pros: it is not very
hard to get 1 bit from the result of crypt_all() there. Cons: it seems
to have linear complexity, so it should be slow on high number of
hashes. Though it may be faster than bitmasks for number of hashes
lesser than number of bits in a vector. It may be the case for salted
hashes (though I guess they should be slow enough to not put the code
there at all). Did you try something like that?
Thanks!
--
Regards,
Aleksey Cherepanov
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.
