[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 29 Mar 2012 05:27:54 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: fast hashes on GPU
On Thu, Mar 29, 2012 at 05:06:59AM +0800, myrice wrote:
> Okay, I am looking at XSHA512. The process is two SHA512_Update with salt
> and password then SHA512_Final.
Please note that these probably trigger just one call to the underlying
SHA-512 compression function (inside OpenSSL) for typical password
lengths. The SHA512_Update calls merely buffer data, and the
SHA512_Final call actually does the hashing (calls the compression
function). You don't need to support password lengths greater than
that. You'll likely implement the SHA-512 compression function on its
own (or reuse Lukas') and have it inlined.
> 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?
Yes, you may reuse any code currently in magnum-jumbo. Please just make
it clear what you have taken and from where. This should also be
reflected on the copyright statements on the source files.
> 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.
This sounds wrong to me. You should not need to modify bench.c at all,
not even for testing. It already does both kinds of benchmarks - for
"one salt" and for "many salts".
Thanks,
Alexander
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.
