Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.