[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130729014219.GA4542@openwall.com>
Date: Mon, 29 Jul 2013 05:42:19 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: Next salt for salted hashes ?
Hi Sayantan,
On Mon, Jul 29, 2013 at 01:40:15AM +0530, Sayantan Datta wrote:
> I'm wondering what is the proper way of getting the next salt which will be
> actually loaded next time when crypt_all is called ?
"Officially", your format's code can't know that. In practice, though,
salt->next will usually be it, so if you really want to, you may
speculatively assume this and have some fallback code for the case when
your guess turns out to be wrong.
> For example: if we have this list say salt0 - > salt1 -> salt2 -> salt3 ->
> NULL
>
> Observation I: When the current salt is say salt0 then the next salt(salt1)
> can be obtained by doing salt->next in crypt_all but when crypt all is
> called for actual next time, it is still called again with salt0. This
> happens when the cracking starts.
Are you trying to say that although salt->next is usually what you need,
sometimes the same salt is repeated (even though salt->next is non-NULL)?
> Observation II: After salt3 , salt0 is called but salt->next is NULL. How
> do I move the pointer to beginning of the uncracked salt list which is not
> necessarily salt0 ?
No reliable way to do that, but again you may speculate that it's salt0
and include fallback code.
> Is there any way I can predict what is the actual next salt that will be
> called in next crypt_all ? I can make a dirty hack(within the format
> itself) to get around both these problems but it is better if I have a
> clean procedure for getting the next uncracked salt.
You can make a pretty good guess about the next salt. Just not a
reliable guess. So do include fallback code if you do that.
> I need this for async transfer of salt and its associated loaded hashes
My expectation was that format authors would cache the salts and their
associated hashes in the GPU card's (or similar) global memory the first
time these salts are seen, and then reuse that cached data (yes, maybe
updating it to remove the cracked hashes, although this is not
absolutely required). With that, you would not need async transfers.
You'd reach full speed starting with the second set of candidate
passwords being tested.
> and bitmapas.
This is trickier, since these can get pretty large. Arguably, though,
the combined size of bitmaps may still be affordable for you to keep all
of them in GPU's global memory. JtR does the same thing on host now.
With salted hashes, typically either hash count for a given salt is low
(so you don't need global memory bitmaps), or the number of salts with
large hash counts is low. While you may have e.g. 100 salts with 1M
hashes each, so you'd run out of GPU global memory for the bitmaps, this
is a relatively obscure case.
Also, async transfers might not fully solve the problem. What if
transferring a 512 MiB bitmap takes longer than executing the kernel
does? (Besides, you'd still need memory for 2 such bitmaps, since the
previous one may still be in use.) Sure, you could increase GWS such
that each kernel invocation takes long enough and such that each bitmap
gets enough use before it's discarded and replaced with next salt's.
But I'm not sure if it's the way to go.
A drawback of transferring large amounts of data to the GPU is that we
become dependent on PCIe bandwidth (lane count and such) and that the
system's power consumption and heat dissipation increases (slightly).
With on-GPU hash comparisons, we're trying to avoid such reliance on
host-GPU transfers.
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.
