[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANJ2NMPT14zRTJjPgMFhm6Sn-OCk_8rCzFTCJBh84ZVB8f-e5w@mail.gmail.com>
Date: Thu, 29 Mar 2012 05:06:59 +0800
From: myrice <qqlddg@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: fast hashes on GPU (was: Working on DES format on CUDA)
> Other options include the Mac OS X hashes known as XSHA512 and XSHA in
> JtR. These are fast, but salted - so the candidate passwords only
> need to be transferred to the GPU once per all salts (then John just
> switches salts until all are tested, and then it moves to the next bunch
> of candidate passwords, which need to be transferred). So you'd be able
> to show better efficiency for the "many salts" benchmarks for these.
Okay, I am looking at XSHA512. The process is two SHA512_Update with salt
and password then SHA512_Final. I see Lukas' cryptsha512.cu already
implements ctx_update for SHA512_Update and sha512_digest for SHA512_Final.
So I can refer to these code on my XSHA512-cuda implementations, is it OK?
Also, I see in bench.c file, the function benchmark_format takes one salt
and then executes crypt_all. This will make multiple candidate
passwords transferring
to GPU. My first step will implement XSHA512 and tested without modify
bench.c. Next I will make many salts with one bunch of candidate passwords
computing on GPU by modifying the bench.c for testing. I think this makes
sense.
Thanks!
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.
