[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTimtq+KwkMYu+T9zBb4YQncjYRSAk2N2yWfC6hqX@mail.gmail.com>
Date: Mon, 21 Mar 2011 03:17:21 +0100
From: Łukasz Odzioba <lukas.odzioba@...il.com>
To: john-users@...ts.openwall.com
Subject: Re: GSOC - GPU for hashes
2011/3/19 Solar Designer <solar@...nwall.com>:
> Hi Lukas,
>
> On Sat, Mar 19, 2011 at 02:22:05AM +0000, ?ukasz Odzioba wrote:
>> I'm interested in the following tasks:
>>
>> JtR: GPU for slow hashes
>> JtR: GPU for fast hashes
>
> Sounds great.
>
>> I would appreciate an additional information about them.
>> For now I've got these questions:
>> Q1) what have to be computed on GPU (check every possible combination
>> paralelly)?
>
> For slow hashes, just the hashes themselves need to be computed on GPU,
> for multiple candidate passwords in parallel. The candidate passwords
> will be generated on the main CPU, and the GPU-computed hashes will be
> checked against those loaded for cracking on the main CPU as well.
>
> For fast hashes, we'll need to discuss this. One approach would be to
> move more of JtR's core code onto GPU - part of candidate password
> generation and hash comparison to be done on GPU. Another approach
> would be to make asynchronous and parallelize those things across CPU
> cores, such that while the GPU is busy computing hashes the CPU is busy
> checking the previous bunch of hashes and generating new candidate
> passwords. Each of these has pros and cons.
>
>> Q2) do you have any prefferences about technology (I would prefer cuda)?
>
> Ultimately, the code will need to run across a variety of GPUs from
> different vendors, not just NVidia. This means multiple technologies
> or/and OpenCL. However, a CUDA-only implementation is within
> consideration for a student's GSoC 2011 project. It will be a step
> forward compared to where we are now.
>
> Some work being done on DES S-boxes will assume AMD GPUs being
> programmed at a low level, though. This is definitely not CUDA. But
> like I said, we may use CUDA too, and another person may do the AMD
> specific stuff.
>
>> Q3) I'm not getting the difference between slow and fast hashes, whats
>> all about or where i can found this type of information?
>
> "Slow" hashes are those that implement multiple iterations of a
> cryptographic primitive for computation of just one hash. The various
> modern Unix crypt(3) flavors are an example of these.
>
> "Fast" hashes are those that rely on a single computation (or very few
> computations) of a cryptographic primitive. NTLM is an example.
>
> There are also some "inbetween" hashes, which we may approach in either
> way. The traditional DES-based crypt(3) is an example, with its 25
> iterations of modified-DES. 25 is a small number, so these hashes are
> pretty fast; just not as fast as those that have no iterations at all.
>
> JtR's current on-CPU candidate password generation and hash comparison
> code can only do up to tens of million of hash computations per second.
> For a hash type where the GPU will "only" compute, say, under 1 million
> of hashes per second, we can use JtR's code as-is. However, for a hash
> type where the GPU is able to compute, say, 100M+ of hashes per second,
> we have to use a more complicated approach (as mentioned above), or the
> task will be mostly CPU-bound.
>
>> Q4) what hashing functions have to be implemented?
>
> There are lots to be potentially implemented (all those supported by JtR
> with the jumbo patch normally, and then more, which gives about 50),
> but no specific requirements on which of these to implement this summer.
> We're yet to decide on this, and our decision may depend on what we're
> reasonably able to do (and achieve good efficiency), and on demand.
>
> I would suggest that we consider all of the slow hashes (there are
> relatively few of these - maybe around 10) and a few most popular of
> the fast ones (NTLM, raw and salted MD5, raw and salted SHA-1, etc.)
>
> I hope this clarifies things for you. Please don't hesitate to ask any
> further questions you might have.
>
> Thanks,
>
> Alexander
>
Thank you for revealing difference about slow and fast hashes, and how
it affect computations.
I've done some research on OpenCL and it is quite similar to CUDA,
perchaps beaucose nVIDIA is much involved into development.
I think i will be able to use it, so AMD cards should not be a
problem, code maintenance will be easier and organisation will have
slot for another student.
About fast hashes, I suppose that the only way to do it right is try
to implement both versions (in multiple variants), make benchmarks and
then choose the most appropriate one. I found FPGA hash crackers on
the Internet. From architectural point of view it might be good idea
to use similar solutions.
In Poland summer break starts in July, and before that we've got egzams.
Q5) Will it be a problem to distribute work in 33:67 properties rather
than 50:50?
Q6) Is there any JtR code documentation(I saw user doc)? It would be
helpful to get familiar with sources.
Q7) I found yours application template and it's the only thing that
"detailed description" must contain, can I add something to it?
Q8) Today i am going to library for Bruce Schneier's "Applied
Cryptography". Are there any good books related to the topic, which I
should look for?
Thanks for help.
Lukas
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.
