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:27:54 +0400
From: Solar Designer <>
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' 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".



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.