Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 28 Mar 2012 23:21:50 +0530
From: SAYANTAN DATTA <std2048@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: JtR: GPU for slow hashes

On Wed, Mar 28, 2012 at 5:54 PM, SAYANTAN DATTA <std2048@...il.com> wrote:

>
>
> On Tue, Mar 27, 2012 at 9:09 PM, SAYANTAN DATTA <std2048@...il.com> wrote:
>
>>
>>
>> On Tue, Mar 27, 2012 at 8:08 PM, Solar Designer <solar@...nwall.com>wrote:
>>
>>> On Tue, Mar 27, 2012 at 05:21:44PM +0530, SAYANTAN DATTA wrote:
>>> >   I have a basic question regarding MSCash2.
>>>
>>> BTW, you probably already found these, but in case not:
>>>
>>> http://openwall.info/wiki/john/MSCash2_simple_code
>>> http://openwall.info/wiki/john/MSCash2
>>>
>>> These are a couple of implementations/descriptions of MSCash2 written by
>>> contributors to JtR.  These may be easier to understand than code
>>> currently in JtR is.
>>>
>>> > In above algorithm two inputs namely ussrname and password are used to
>>> > produce a certain hash.Then the generated  hash is compared with the
>>> stored
>>> > value and if they are equal then the username and password entered are
>>> > correct.Now we hit and try different values of password to produce a
>>> hash
>>> > which matches the given value .So does this mean the username is some
>>> fixed
>>> > string??
>>>
>>> For one hash being cracked, yes.
>>>
>>> > i.e is the username known to us beforehand and we only have to
>>> > guess the password?
>>>
>>> Yes.
>>>
>>> > Right now my code assumes the username a fixed string.Is it all right??
>>>
>>> Maybe not, depending on what you mean by assuming a fixed string -
>>> compile time constant vs. runtime value fixed only for a given hash
>>> currently being processed (out of many loaded for cracking).
>>>
>>> JtR supports cracking of many hashes at once, which may correspond to
>>> different usernames.  In MSCash2, the usernames are effectively used as
>>> salts - so JtR formats' interfaces for salts are used to support them.
>>> You also need to support running with an arbitrary set of salts
>>> (usernames) and hashes loaded for cracking at once (e.g., there might be
>>> 10000 hashes with 9900 different salts).
>>>
>>> Also note that you only need to implement the PBKDF2 step on GPU - the
>>> rest may stay on CPU.  Lukas did the same in his CUDA code (based on my
>>> suggestion).  This may simplify the task, and it will let us easily
>>> reuse the PBKDF2 with SHA-1 implementation for things such as WPA.
>>>
>>> Alexander
>>>
>>>
>>>
>> hi,
>>
>> Yeah I mean runtime value fixed only for a given hash being processed.
>>
>> And thank you for the suggestion.
>>
>> -Sayantan
>>
>>
>   Hi ,
>
>   Here are a few problems I'm facing.Since ATI 4000 series gpus don't
> support byte_addressable_store I have to work around this problem by using
> only uint as the data type for temporary data storage.This problem exsist
> with many of the hash algorithms already implemented with openCL eg MD5,4
> etc.However ATI 5000 series and above seems to support
>  byte_addressable_store.So the exsisting codes should work fine on 5000 or
> above GPUs but for 4000 series or below they need to be reimplemented.The
> workaround is also causing some performance penalties.
>
> -Sayantan
>

Hi,

  Since my GPU dosen't support byte_addressable_store it is becoming an
increasingly uphill task to implement the HMAC_SHA1 algorithm.Using the
uint[]  instead of uchar[] is a probable solution but debugging the
code becomes very much time consuming.
   I  have also considered using 4 uchar16 vectors to  replace single
uchar[64] array but it is resulting in too much branching in the code.If
you have any suggestion please let me know.

-Sayantan

Content of type "text/html" skipped

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.