[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Mon, 10 Aug 2015 19:15:20 -0400
From: Matt Weir <cweir@...edu>
To: "john-users@...ts.openwall.com" <john-users@...ts.openwall.com>
Subject: Re: Can you help me? I need more valuable papers about
time-memory trade-off.
Hi Marek,
I should start by saying over on the John-dev mailing list there has
been an ongoing conversation about Rainbow Tables. The archive of it is
available here:
http://permalink.gmane.org/gmane.comp.security.openwall.john.devel/12217
Considering the wide appeal Rainbow tables have, I don't have any issues
talking about them on john-users but you might want to consider moving the
conversation over to john-dev just so everyone doesn't have to keep two
different threads in mind.
>> ...is very educational but doesn't tell anything useful about reduction
functions. How are that
>> functions created?
If you are really interested in the nitty gritty of reduction functions I'd
recommend checking out chapters 4.4 and 4.5 of my dissertation which is
available here:
https://sites.google.com/site/reusablesec/Home/presentations-and-papers/Weir_C_Dissertation_2010.pdf
There I talked about strategies of making a reduction function for pure
brute force, indexed/masked brute force, markov tables, and dictionary
based tables. While I only focused on variants of rcrack, the way ophcrack
used their reduction functions was roughly similar though there were some
differences. It's been years since I looked at ophcrack though so I don't
actually remember what those differences were ;p
As to your suggestion of adding the salt into the reduction function, the
reason why no one currently does that is simply because it increases the
lookup time for hashes. Aka when cracking a hash if you know what your salt
is, (which you should since by it's very nature the salt shouldn't be a
secret if you have access to the hashes), then there is no need to generate
and check chains/hashes which don't use the target salt. That's why you'll
see a separate table created for each salt you want to target.
To put it another way, if you have one thousand salts, you can reduce the
lookup time by a factor of a thousand by creating a table per salt vs
including the salt in your reduction function. That's an easy and
significant improvement so that's why people construct their tables that
way. In all reality, all of the salt based tables I've seen have focused on
hashes where the username was the salt so a limited number of tables were
created for popular users like 'sys' or 'administrator'.
Matt
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.
