Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Sun, 6 Dec 2015 16:17:56 +0300
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: phpass OMP_SCALE

magnum -

We have OMP_SCALE in phpassMD5_fmt_plug.c set to 1.  This appears
insufficient, often resulting in phpass benchmarks showing less than
half the speed of md5crypt ones.  Increasing this just slightly (to 2)
makes most of the problem go away for me (on super), but optimal (in
terms of benchmark speeds) appears to be 16 when running with
GOMP_CPU_AFFINITY set and 64 or so without.  32 appears to work
reasonably well in either case (on super).

So we can try just setting it to 32, or at least increasing it slightly
(not keep it at 1).  Of course, a drawback is that "restore points"
become less frequent when running with a lot of salts or/and with high
cost phpass hashes (in fact, when all of the loaded hashes are much
higher cost than our benchmark defaults, increasing OMP_SCALE might not
even be needed for optimal performance at those).  Unfortunately, with
our current code OMP_SCALE is applied before we know what the costs of
loaded hashes are.  We could move it from init() to reset(), and have
the costs considered there, but for now I think we should simply use a
larger OMP_SCALE.  Would you give this a try and commit?

With phpass OMP_SCALE 32:

[solar@...er src]$ GOMP_CPU_AFFINITY=0-31 ../run/john -test -form=phpass
Will run 32 OpenMP threads
Benchmarking: phpass ($P$9) [phpass ($P$ or $H$) 128/128 AVX 4x3]... (32xOMP) DONE
Speed for cost 1 (iteration count) of 2048
Raw:    421647 c/s real, 13148 c/s virtual

which compares favorably against:

[solar@...er src]$ GOMP_CPU_AFFINITY=0-31 ../run/john -test -form=md5crypt
Will run 32 OpenMP threads
Benchmarking: md5crypt, crypt(3) $1$ [MD5 128/128 AVX 4x3]... (32xOMP) DONE
Raw:    729600 c/s real, 22771 c/s virtual

meaning that without md5crypt's extra complexity, it could run at:

[solar@...er src]$ bc <<< 421647*2048/1000
863533

This is how it should be - phpass being more efficient at its use of MD5.

Alexander

Powered by blists - more mailing lists

Your e-mail address:

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