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

Hi Sayantan,

It's great that you're continuing work on this.  Thank you!

On Wed, Dec 5, 2012 at 1:24 PM, Sayantan Datta <std2048@...il.com> wrote:
> I am working on patching the source at run time.

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.

> However it seems that
> during benchmark , salt is changed every time before a crypt all() call is
> made.  This is negatively affecting the benchmark results because every
> time the salt is changed we need to rebuild the kernel which is very slow.
> So is it possible to run the benchmark without changing the salt every time
> ? In real world cracking how often is the salt changed ?

It's changed once per crypt_all() call as well, except in the special
case when we're cracking hashes with only one salt (then it's not
changed).  The salt changes are made infrequent enough by keeping
keys_per_crypt large enough.  Rebuilding from source is just too slow,
though.

On Wed, Dec 05, 2012 at 11:57:41PM +0530, Sayantan Datta wrote:
> I have managed to solve the above problem by storing the all the kernels
> corresponding to different salt in host memory. Hence there is no need to
> rebuild kernel every time the salt is changed. However the amount of memory
> used can be quite high depending upon the number of different salts loaded.
> I have posted the patch in git repo.

Curious.  How much memory is consumed per salt?  How much is consumed
when all 4096 salts are present?  And how long does it take to build the
4096 kernels?  (If this takes too long to measure, then provide the
number e.g. for 41 or 410.)

Thanks again,

Alexander

Powered by blists - more mailing lists

Your e-mail address:

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