[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 7 May 2015 17:39:45 +0300
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: get_binary_*() and get_hash_*() methods
Aleksey,
I'll skip commenting on things that I think you already figured out.
On Thu, May 07, 2015 at 12:50:33PM +0300, Aleksey Cherepanov wrote:
> It looks like crypt_all() gets struct db_salt *salt? Is it the whole
> db? The salt was set up by set_salt() so it should be the db, right?
It's the portion of db corresponding to the current salt.
> 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.
It's been reverted since. I never intended to commit it as-is, even
though it worked and provided decent speeds. Someone else got it into
jumbo, then reverted along with sync'ing with core.
> Is it worth to put several implementations into crypt_all() to handle
> different counts efficiently? I guess, it won't be noticeable in huge
> attacks but implementing scenario with small chunks of work for
> distribution it may affect performance, no? Though bigger crypt_all()
> may reduce performance due to code cache, will not it?
It depends.
Alexander
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.
