[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+TsHUA+hzisNhFbLsFeSP3mup6ez4cR8LGQCc+3Zqjf1W2J=w@mail.gmail.com>
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.
