[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20150629173010.GA7725@openwall.com>
Date: Mon, 29 Jun 2015 20:30:11 +0300
From: Aleksey Cherepanov <lyosha@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: Re: precomputed attacks for john: rainbow tables and
other ways
On Mon, Jun 29, 2015 at 08:59:15AM -0400, Matt Weir wrote:
> >> Another idea: split attack into blocks 256 candidates each, for each>.
> >> block build a 256 byte look up table: first byte of hash -> number of
> >> candidate in block. So having N hashes, you get N bytes of spaces and
> >> look up for 1 hash in N/256 hashing operations.
>
> Sorry I'm not really following you. Are you talking about a pure hash
> lookup table, (aka no compression through the use of chains)? If so there's
> various ways to lay it out on disk depending on how much disk space you
> want to use and your tolerance to false alarms and lookup time. It comes
> down to what you want to optimize. I guess we could discuss different ways
> to do that if you are interested. Of course if you are talking about
> something completely different then I guess tell me more ;p
Yes, I mean pure hash->candidate lookup table without chains. I guess
it is not very interesting practically but it can be a good measure
for other approaches.
Really, some bytes to some bytes table has problem with collision: 2
or more hashes can have the same value of the byte for lookup, so a
trickier structure is needed.
Are pure hash->candidate lookup tables practical? Won't we bump into
hdd reading limit for big sets?
Thanks!
--
Regards,
Aleksey Cherepanov
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.
