Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sat, 10 Aug 2013 09:37:18 +0530
From: Sayantan Datta <std2048@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: Self-test-specific code defeats the whole idea of self-test

On Sat, Aug 10, 2013 at 9:26 AM, Sayantan Datta <std2048@...il.com> wrote:

>
> On Fri, Aug 9, 2013 at 7:05 PM, magnum <john.magnum@...hmail.com> wrote:
>
>> We should definitely add a mask-mode self-test when fmt.method->set_mask
>> != fmt_default_set_mask.
>>
>> How is set_mask() used? Is it called once before the normal
>> set_key/set_salt/crypt_all loop or is it called within that loop?
>>
>> We should also add mask mode to the benchmark, so we get to see some new
>> cool speeds. Maybe this will be a third set of figures? Perhaps another
>> "Only one salt" (or "Raw") that uses mask mode?
>>
>
> set_mask() is called once before cracking starts i.e after reset(db!=NULL)
> and before first crypt_all(salt!=NULL).
> Please note that mask mode can be used by any format even though they do
> not support key generation on GPU.
> I use the flag db->max_int_keys to specify whether a format supports
> internal key generation or not. This flag is currently supposed to be set
> inside reset. When we implement self-test for mask mode we would have to
> move this flag to format specification and set the flag during format
> initialization.
>
> But before we can implement a test for mask mode, we need to remove the
> restriction self-test imposes.
>
> Regards,
> Sayantan
>
>

Also currently the mask is processed inside reset, which I think should be
be moved to format initialization. I'll put this in my next week priority.

Regards,
Sayantan

[ CONTENT OF TYPE text/html SKIPPED ]

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ