[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20121205205932.GA22536@openwall.com>
Date: Thu, 6 Dec 2012 00:59:32 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: bitslice DES on GPU
On Thu, Dec 06, 2012 at 02:16:21AM +0530, Sayantan Datta wrote:
> On Thu, Dec 6, 2012 at 1:08 AM, Solar Designer <solar@...nwall.com> wrote:
>
> > We need to be patching binary, not source. For example, you could find
> > the pointers to patch by looking for their known values, then making
> > sure their count is as expected. You'd record their addresses in an
> > array. Then reuse that array to patch them each time a new salt it set.
>
> I'm confused!! Do you mean we need to patch the binaries that we get after
> a call to clBuildProgram() ?
Yes, and do that in memory (does the API allow that?)
> OpenCL binaries are generally elf objects and
> require additional dependencies to parse them.
You don't have to parse them (or you'd have to disassemble and
"understand" the code too). You need to search them for known addresses
(pointer targets). This is not 100% reliable, but it can get close -
especially if you make e.g. two builds with different hard-coded salts
(e.g. with all bits inverted) and then make sure that you happen to
identify the exact same sets of addresses for both (in addition to the
address count being right). In practice, even one build plus the
address count check will likely be good enough.
> Or do you mean we should try
> to avoid disk i/o caused by patching sources directly? Please clarify!!
No. We need to avoid not only disk accesses, but also re-compiling from
source for each salt.
> For instance when 35 different salts are loaded ,john consumes a total of
> 100MB of RAM. Also the test suit containing 1500 hashes consumes around 1.2
> - 1.3 GB memory and takes around 1050 seconds to complete the test. Given
> that most of the time is spent on building kernels, 4096 different salt
> should consume around 4GB of memory and take around 20-30 minutes to build
> all the kernels.
OK. A half an hour delay is really nasty, but in some cases it may be
acceptable. Yet we can and should do better.
Alexander
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.
