Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 25 Mar 2012 05:02:19 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: Self test woes

On Sat, Mar 24, 2012 at 12:03:28PM +0100, Lukas Odzioba wrote:
> We should think more about testing. I often had problems because
> format working great on tests but not on a real crack. I tried to
> solve it using unit testing last summer, it helped a bit, and thanks
> for that I could propose some "trivial" tests that could be included
> to jtr testing routine like simple comparision strcmp(arg1,arg2),
> where set_key(k,arg1), and arg2=get_key(k). Problem might sound stupid
> but I fall into if 2-3 times and others might too.

We had this test for ages:

		if (strncmp(format->methods.get_key(index), plaintext,
		    format->params.plaintext_length))
			return "get_key";

(it was already in there even 10 years ago).  Is this somehow not what
you mean above?

> Maybe we could separate tests from benchmarks, what is now the problem
> (formats needs a lot of hashes to get good performance).

We already have separate code for tests and benchmarks.  Both use the
same set of test vectors, though.  Do you feel this needs to change?

> All my formats now are using predefined or calculated once
> keys_per_crypt value and do not care about crypt_all(int n) argument
> at all.
> 
> Current solution has at least two disadvantages:
> 1) test takes too much time
> 2) we are spending gpu power on wordlist attacts, when size of
> wordlist is much smaller than keys_per_crypt.

The wordlist mode issue is not with self-tests.  It is with you not
using the argument to crypt_all().  I understand that it may be
difficult to use it efficiently when your implementation is
parallelized.  I've just checked that wordlist.c merely calls
crk_process_key(), so it shouldn't result in any unnecessary calls to
crypt_all() with a less than full buffer until we're actually out of
candidate passwords to test (in terms of both input words and rules).
When we are, the issue is fundamental - either you process the argument
to crypt_all() or we waste processing time on the last block.

Alexander

Powered by blists - more mailing lists

Your e-mail address:

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