Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<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

Your e-mail address:

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.