[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <4F1DCB3B.2060000@linuxasylum.net>
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
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
