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 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.