Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Mon, 28 Aug 2006 17:50:46 -0400
From: John <guipenguin@...il.com>
To: john-users@...ts.openwall.com
Subject: Using a pre-computed list of alphanumeric strings. (not rainbow tables)

Before someone answers this message, yes I do understand what a salted hash
is, and why running a rainbow table on such a hash would be
ineffective...but please read until my last question. I got thinking more
about this.... if I have a pre-computed hash table with hashes of every
alphanumeric combination up to say, 14 chars long, why couldn't something
like this be used in place of a word list?

JTR can use standard dictionary lists correct? and JTR has to take each one
of these words and at one point or another encrypt this word...before
matching against what needs to be cracked. Why can't you compute hashes
ahead of time, and use this in place of a dictionary list?

OK..so this still wouldn't work correctly...because of the salt....but..John
the Ripper has to some how figure out what this salt is to proceed and use a
dictionary word, even though it doesn't just encrypt the dictionary word,
and match this hash against the encrypted password.

SO getting away from rainbow hash tables for a second....Would it be faster,
to pre-compute a 'list' of every possible alphanumeric combination untill 14
chars, and use this in place of a dictionary list? There for John the Ripper
when brute forcing, wouldn't have to generate a string, encrypt the string,
and match it...it could simply use it like a dictionary list...wouldn't this
be faster? and I could ensure that in my 'list' was the password....I just
have to find which one it is.

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ