Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Mon, 24 Dec 2012 23:56:24 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: bitslice DES on GPU

Sayantan -

On Tue, Dec 25, 2012 at 12:45:35AM +0530, Sayantan Datta wrote:
> Although I have located all the 48 indexes in the binary, but modifying
> them works only for a few salts. The problem is the offset values are
> drifting with different salts and I can't generalize the whole process for
> all of them. Of course we can find the offset values individually for all
> the salts but it would be a task of astronomical proportions!!

I suspect that there might be special cases (more compact encodings)
possible for smaller offsets - and then you can't patch them to larger
offsets.  If so, you need to use large offsets in all 48 indices at
compile time (but make them distinctive so that you can locate them).
(Yes, they would not correspond to any valid salt value, but so what.)

>    Maybe we should think of some other techniques rather than modifying the
> binaries.

We definitely need to include some fallbacks, such as for GPUs
unsupported by our binary patching hack - I think your older code with
runtime application of E[] could be it.

> For example , we can pre-compile all the 4096 kernels save them
> on disk and load them before we start cracking/benchmark. While pre
> compiling we could also use multiple cores to reduce the time required.
> Disk space required is less than 600MB and time required should be less
> than 10min for a quad core. This would be more general, reliable and
> require far less maintenance.

This is a possible fallback mode, but I suspect most users won't like
it.  I think we could try e.g. building 256 kernels where each would have
8 of the salt bits hard-coded and the remaining 4 left to be applied at
runtime with E[].  This will provide medium performance.

For overall good performance (both c/s rate and startup time), I still
like the binary patching approach.  We just need to make it work.  We
might extend it beyond E[] then - also apply it for some key bits that
are always-0 or always-1 for a given (large) subset of candidate
passwords being tested.

Alexander

Powered by blists - more mailing lists

Your e-mail address:

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