Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Mon, 23 Jan 2012 22:03:55 +0100
From: Samuele Giovanni Tonon <samu@...uxasylum.net>
To: john-dev@...ts.openwall.com
Subject: best approach to cmp_all and cmp_one

hello,
sorry to bring back another question about cmp_all and cmp_one.

As i've understood from previous posts cmp_all:

1. cmp_all() is not always called.  When the number of hashes for a salt
is above a threshold, a get_hash*() function is called instead.

2. cmp_all() may be called multiple times if there's more than one hash
for a salt, but the threshold mentioned above is not reached.

3. cmp_one() and cmp_exact() may be called in either case, but only when
cmp_all() or get_hash*() checks indicate a possible match.

in the whole opencl formats i've been working so far i had crypt_all
enqueue the long list of password to be  hashed and just read back
the 1/5 of hashes .

then, in case cmp_all will be called i got one single call to read the
rest of the 4/5 of the hashes with a


if (b == outbuffer[i]) {
       clEnqueueReadBuffer(queue[gpu_id], buffer_out, CL_TRUE,
                 sizeof(cl_uint) * (SSHA_NUM_KEYS),
                 sizeof(cl_uint) * 4 * SSHA_NUM_KEYS, outbuffer2, 0,
                 NULL, NULL);



This is good for speed because i check the rest of the hashes only when
i get a first "good start", if not i'm saving bandwith of the PCI-E.

however: if cmp_all get another call before a crypt_all i will just read
garbage; would be good on having a global semaphore to avoid a
clEnqueReadBuffer if there's hasn't been any previous crypt_all or there
are more elegant ways to solve the problem ?

second: i was thinking on getting the i-th hashes instead of the whole
buffer but i discovered cmp_one goes incremental, let me explain by an
example

suppose NUM_KEYS is 1000 and cmp_all(1000) is called and
b == outbuffer[i] is TRUE for 995, then cmp_one will be called like that:
cmp_one(0)
cmp_one(1)
.....
cmp_one(995) and password is found.
wouldn't be best to have cmp_one start at 995 and incrementing until
NUM_KEYS is reached instead of starting from the beginning or to do that
there will be side effects or a major rewrite of the code ?


next question: saltless password.

cmp_all is not called for saltless password due to 1. , so instead
you get cmp_one and get_hash_xxx .
This unfortunately makes me have 4 clEnqueReadBuffer which are quite
expensive and do something like that.

clEnqueueReadBuffer(queue[gpu_id], buffer_out, CL_TRUE,
    sizeof(cl_uint) * (1 * SSHA_NUM_KEYS + index), sizeof(a),
    (void *) &a, 0, NULL, NULL);
if (t[1] != a)
        return 0;
clEnqueueReadBuffer(queue[gpu_id], buffer_out, CL_TRUE,
    sizeof(cl_uint) * (2 * SSHA_NUM_KEYS + index), sizeof(b),
    (void *) &b, 0, NULL, NULL);
if (t[2] != b)
        return 0;
clEnqueueReadBuffer(queue[gpu_id], buffer_out, CL_TRUE,
    sizeof(cl_uint) * (3 * SSHA_NUM_KEYS + index), sizeof(c),
    (void *) &c, 0, NULL, NULL);
if (t[3] != c)
        return 0;
clEnqueueReadBuffer(queue[gpu_id], buffer_out, CL_TRUE,
    sizeof(cl_uint) * (4 * SSHA_NUM_KEYS + index), sizeof(d),
    (void *) &d, 0, NULL, NULL);
return t[4] == d;

to solve this problem i'd have to revectorize the opencl output,
or there are other way to make cmp_all work on saltless passwords?

Cheers
Samuele





Powered by blists - more mailing lists

Your e-mail address:

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