[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+TsHUDf-NwSrC07hSfTS8EZawv+rD2qJyRkw=WqpCxOT0c5XA@mail.gmail.com>
Date: Wed, 28 Mar 2012 17:54:22 +0530
From: SAYANTAN DATTA <std2048@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: JtR: GPU for slow hashes
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
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.
