[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20111121171245.GC26821@openwall.com>
Date: Mon, 21 Nov 2011 21:12:45 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: best way to get ciphertext
On Mon, Nov 21, 2011 at 05:42:55PM +0100, Samuele Giovanni Tonon wrote:
> between crypt_all and cmp_all (or cmp_one) get_hash_N() are called
Not exactly. If get_hash*() is called, then cmp_all() won't be called
(for this salt), and vice versa.
cmp_one() and cmp_exact() may be called in either case, but only when
cmp_all() or get_hash*() checks indicate a possible match.
> and they need the first chunk to be processed
> in order to return the right data.
Right, unless you disable get_hash*() calls somehow, you need to have
crypt_all() do its job... well, or you can defer that until either
cmp_all() or get_hash*() is called - that is, have a shared function
(internal to your code) that you'd call from all of these functions
unless it was already called after the last change of key+salt.
> this of course applies if i want that primary test to work and not just
> having get_hash_N() and binary_hash_N() return TRUE no matter what
> (which is kind pointless) .
They don't return true or false, they return hash values. Of course,
you can disable that by having them return constants, but that wouldn't
make cracker.c call cmp_all() - instead, it would be calling cmp_one().
Oh, I just realized that if you simply set all binary* function pointers
to fmt_default_binary_hash, that will make ldr_init_hash() not use the
hash tables. This eliminates the need for the FMT_* flag I mentioned in
other messages. On the other hand, it's even nastier than the flag,
because it also disables loader's own use of the hash functions (so
loading will be slow).
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.
