[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANJ2NMNtXjR4mOaWTNzOK6xgZHiJrqaswoVDhzRPFDhHD1BXfg@mail.gmail.com>
Date: Wed, 18 Jul 2012 16:32:50 +0800
From: myrice <qqlddg@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: reset()
On Wed, Jul 18, 2012 at 10:13 AM, Solar Designer <solar@...nwall.com> wrote:
> myrice, magnum, Jim, all -
>
> Here's how I am introducing reset() - a format method that may transfer
> salts/hashes to GPU.
>
> /* Called whenever the set of password hashes being cracked changes, such as
> * after self-test, but before actual cracking starts. When called before a
> * self-test or benchmark rather than before actual cracking, db may be NULL.
> * Normally, this is a no-op since a format implementation shouldn't mess with
> * the database unnecessarily. However, when there is a good reason to do so
> * this may e.g. transfer the salts and hashes onto a GPU card. */
> void (*reset)(struct db_main *db);
>
> ..
> Unfortunately, the existing self-test won't be able to test such formats
> for real (including their on-GPU storage of salts/hashes). We may
> revise the approach to self-testing later.
>
I see your patch. If we passed NULL before self-test or benchmark, we
could not use reset() to store hashes/salts in self-test or benchmark.
So selt-test and benchmark cannot measure stored loaded hashes/salts
on GPU, right?
Thanks
myrice
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.
