Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 13 Jun 2013 19:37:17 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: Mask mode for GPU

On Thu, Jun 13, 2013 at 09:04:35AM +0530, Sayantan Datta wrote:
> Okay. So first of all I need to figure out a way to generate the keys 
> corresponding to the mask. After that we may apply the mask as we like.

Right.  Our rules preprocessor implements something very similar -
in fact, I think we might want to support its syntax as well.  For a
trivial implementation, we could simply be calling rpp_*() from the mask
mode implementation - and it'd just work for rpp's variation of the
syntax.  However, rpp is mostly unoptimized (it wasn't meant to be used
from a performance-critical place) and it implements its syntax only
(not the PasswordsPro/hashcat "mask attack" syntax).

The algorithm to implement - to traverse a mask with minimal code
complexity - should be very similar to rpp's.  (I think myrice started
to implement something more specialized, which would result in larger
code size.  I think rpp's approach is better.)

> Also I think it is better to keep things simple on the gpu part:
> I am thinking to using only four configuration ?l ,?u, ?d, ?[0x20-0x2f] 
> on GPU. Any other combination will need to be generated by the CPU.

I dislike this idea.  To make things on the GPU simple, you should
support arbitrary charsets (lists of characters provided by the host).
Then you (initially) don't implement any specialized code for specific
charsets (implement only the most generic version).  When you're ready
to increase code complexity in order to achieve greater efficiency with
specific formats and specific common charsets, you'd implement that (for
a handful of charsets) as an optional enhancement (available in some
formats and for some charsets, but not in all formats and not for all
possible charsets).  You wouldn't even have to implement specialized
support for the same charsets in each format (e.g., at some point in
time we might have specialized/optimized code for ?l and ?d in one
format, but only for ?d in another - and it'd work transparently).

Alexander

Powered by blists - more mailing lists

Your e-mail address:

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