Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 7 May 2015 17:39:45 +0300
From: Solar Designer <>
Subject: Re: get_binary_*() and get_hash_*() methods


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.


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.