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.