Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 05 Apr 2015 00:01:15 +0200
From: Frank Dittrich <frank.dittrich@...lbox.org>
To: john-dev@...ts.openwall.com
Subject: Re: [GSoC] John the Ripper support for PHC finalists

On 04/04/2015 09:08 PM, Agnieszka Bielec wrote:
> I've discovered that --cost modifies also fmt_test structure in fmt_main
> (but only with the --test flag!). I can take advantage of this.
> previously I was debuging without the --test flag and I saw that first
> are executed init() and reset() and after them functions tunable_cost_*.
> 
> If I change one hash in fmt_test to a wrong one
> I have
> ./john --test --format="django-scrypt" --cost="14,8,1"
> Speed for cost 1 (N) of 14, cost 2 (r) of 8, cost 3 (p) of 1
> Raw:    403 c/s real, 14.0 c/s virtual

Somehow in your test output these two lines (or some similar lines) are
missing:
Will run 8 OpenMP threads
Benchmarking: django-scrypt [Salsa20/8 128/128 AVX]... (8xOMP) DONE

The first line (mentioning the number of OMP threads is to stdout and
occurs only for OMP builds.
But there should have been a "Benchmarking ..." line.
You shouldn't have dropped this line.
403 / 14.0 is about 28.78, so I assume you were running the test with 32
OMP threads.

You should have quoted the output of
./john --test --format=django-scrypt
without any --cost parameter.
I assume your first example is without changing any test hashes.
In that case it wouldn't matter whether or not you specify
--cost=14,8,2, because, apparently both django-scrypt tests have the
same tunable cost values.

When I try to increase the value of any of the 3 tunable costs, I get
Will run 8 OpenMP threads
Benchmarking: django-scrypt [Salsa20/8 128/128 AVX]... (8xOMP) FAILED
(--cost pruned all 2 test vectors)

This is expected behaviour.

> 
> ./john django --format="django-scrypt" --cost="14,8,1"
> Self test failed (cmp_all(1))

Again, you should have copied the exact output, and not rephrase it in
your own words, this require leaves others to guess what exactly the
output was.

If I understand you correctly, you manipulated a hash, changing just a
cost value so that the test would become invalid.

When I reduce the value of the second cost parameter of the first hash
from 8 to 4 (making it invalid), I get

(bleeding-jumbo)run $ ./john --test --format=django-scrypt
Will run 8 OpenMP threads
Benchmarking: django-scrypt [Salsa20/8 128/128 AVX]... (8xOMP) FAILED
(cmp_all(1))

This is not a bug, but expected behavior.


For
$ ./john --test --format=django-scrypt --costs=14,8,1
the self test passes, because the 14,4,1 test is skipped.

This is (most likely) expected behavior as well.

When I try an actual cracking run, not a --test run with this broken
self test, I get:

(bleeding-jumbo)run $ ./john --format=django-scrypt hashes.django-scrypt
--costs=14,8,1
Loaded 2 password hashes with 2 different salts (django-scrypt
[Salsa20/8 128/128 AVX])
Remaining 1 password hash
Will run 8 OpenMP threads
Self test failed (cmp_all(1))


> It's a bug? (auto tune for all hashes)

This is totally unrelated to whether or not the format auto tunes for
the hashes to be cracked or not. It is just about what hashes is the
format supposed to see in this case.
Whether it is intended behavior or a bug to filter self tests according
to --cost parameters during self test, but not in a real  cracking run,
I don't know.
I think magnum has to decide it (and may be improve the documentation).

But for your implementation of the pomelo format, the outcome of this
decision shouldn't matter.
You shouldn't care about whether or not --cost was specified on the
command line.

If you are in a real cracking run, not a --test run, all that IMHO
matters in the self test is that it passes.
Concentrate on optimizing the real cracking run based on hashes loaded.
Optimizing the --test run for the cost values of the first 2 hashes
(instead of all the self tests) for a --test run is secondary IMHO.
Ignore the performance of the self test in a real cracking run (also IMHO).


Frank

Powered by blists - more mailing lists

Your e-mail address:

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