Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Mon, 29 Jun 2015 20:30:11 +0300
From: Aleksey Cherepanov <>
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?


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.