Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Mon, 7 Jan 2013 04:03:23 +0400
From: Solar Designer <>
Subject: des-opencl

Sayantan -

While posting comments here:

I tested des-opencl currently in unstable-jumbo:

OpenCL platform 1: AMD Accelerated Parallel Processing, 2 device(s).
Using device 0: Tahiti
Benchmarking: Traditional DES [OpenCL]... DONE
Many salts:     43805K c/s real, 141669K c/s virtual
Only one salt:  25022K c/s real, 41287K c/s virtual

As we know, this is reasonable speed given no specialization for a salt
value yet and given the formats interface bottleneck.  However, when I
went to test it on an actual password file, I found that:

1. Detection of matching salts does not work.  This is easily fixed by
changing BINARY_SIZE and SALT_SIZE in opencl_DES_fmt.c to be
sizeof(WORD) (for consistency with your other changes) rather than
ARCH_SIZE (a leftover from the CPU-based format).  Please apply this
change.  I briefly tested it, and it works for me (fixes the problem,
does not introduce side-effects).

2. The speed seen during actual cracking is a lot lower - about 1M c/s,
not 44M c/s as --test would suggest (this is for many salts).  Why is
that?  How to avoid this problem?

A guess: you're using global memory somewhere, so caching helps when
there are only a handful of different plaintext passwords/salts being
hashed repeatedly.  It could be something entirely different, though.

Maybe you've recently made "optimizations" and did not test their effect
other than on --test speeds, which do not always reflect real-world
speeds.  Maybe you need to revert some changes.

When we were at around 20M c/s for --test, this was a speed we could
actually achieve, right?  I vaguely recall actually achieving it in a
run on a password file.



Powered by blists - more mailing lists

Your e-mail address:

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