[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Mon, 18 Mar 2013 14:26:41 -0400
From: Brian Wallace <bwall@...nbwall.com>
To: john-dev@...ts.openwall.com
Subject: Idea to increase plaintext length for GPU based hashes
Hey,
One issue I am finding with many of the GPU based formats Jumbo supports
is that they have quite small max plain text values. The reason for
this is that I think in general, there is a big performance hit when
scaling up the max password length because of the additional memory
required. I noticed a few design issues when increasing the plain text
length of pwsafe-opencl. In my mind, it boils down to two issues, and
one I have a proposed solution for. The two issues are required buffer
sizes for increase for every plain text to access it per kernel thread,
and running multiple transforms when the plain text and possible salt
bypasses the length of the hash's block size. The former is what I
purpose a solution for, although I have not had the time to implement it
yet.
For the most part, we use a single buffer to store the plain texts,
generally with a static sized char array then a value describing the
length. This solution proposes a second buffer be used as well as
changing the first buffer.
The first will be filled with static sized objects that contain the
length of the password and the offset of the password in the other
buffer.(Pointer buffer)
struct PointerObject{
unsigned int length;
unsigned int offset;
}
The second will have the passwords lined back to back(no need for a
terminating null), and will not be a static size(different for each
executed kernel.(Data buffer)
Each kernel thread will first access the pointer buffer, and get the
pointer struct for its index, then use the offset value to find where
its password starts in the data buffer. It would then use
PointerObject.length bytes for the input to the hashing function.
While this may have some overhead compared to small static sized
password buffers, it will allow for the password lengths to be scalable
with minimal impact to drastically increase the maximum plain text
values for more algorithms that implement it.
I don't have the time to currently implement this, or to formally test
it, but I thought it would be a good idea to mention the design idea for
future changes.
-Brian Wallace
------
bwall@...nbwall.com - Not to be confused with openwall.com
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.
