[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8d48352a0aa68a624712f8a09828db05@smtp.hushmail.com>
Date: Fri, 9 Aug 2013 15:35:19 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Self-test-specific code defeats the whole idea of self-test
On 8 Aug, 2013, at 21:38 , Sayantan Datta <std2048@...il.com> wrote:
> On Fri, Aug 9, 2013 at 12:29 AM, magnum <john.magnum@...hmail.com> wrote:
>> Apparently you have added specific get_key_self_test() and crypt_all_self_test() functions in four OpenCL formats and they even have self-test specific kernels. If we go that path, we can just as well drop the whole idea of self-tests, no? It is totally OK in an experimental branch but hacks like that does not belong in bleeding at all IMHO, other than for very short time if you have a specific plan (but that should ideally evolve in a topic branch). In my book this is four release blockers.
>
> We can't use the same code we use for self test for other purposes. Self-test imposes a specific set of restrictions which diminishes performance.
So we should change the self-tests.
> The best I can do is give an illusion that the same kernel is being used for all purposes but internally within the kernel the self-test will follow the same code path as we are following now. Just it would lead to more branches inside the kernel eating up i-cache and reducing performance. As you might have seen all the kernel inside a format uses same algorithms. So the self-test checks at least the main core algorithm for the format.
>
> * The count passed to cmp_all() must be equal to crypt_all()'s return value.
> * If an implementation does not use the salt parameter or if salt is NULL
> * (as it may be during self-test and benchmark), the return value must always
> * match *count the way it is after the crypt_all() call.
I always pictured the above is subject to change. I'm not sure what to change or how though.
> The above restriction doesn't allow all the modes to follow same code path. If this restriction is removed I might be able to use the same kernel for self-test and other modes except mask mode. For mask-mode we might need to design a new test.
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?
magnum
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.
