[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120621192039.GB26823@openwall.com>
Date: Thu, 21 Jun 2012 23:20:39 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: formats interface enhancements
On Thu, Jun 21, 2012 at 09:44:21AM -0500, jfoug wrote:
> >From: Solar Designer [mailto:solar@...nwall.com]
> >source()
>
> Actually it is get_source() in the current bleeding. NOTE renaming would
> be trivial, if we have to, but my intent behind the name was:
>
> binary(), salt() are convert from the outside format, into an internal
> format
>
> set_salt() set_key() are setters.
> get_key() is a getter of the original set_key().
>
> binary_hash() / get_hash() are also the setter/getter 'like' functions, but
> named differently.
>
> My feeling was that the source() was a getter, so I named it get_source().
> It is meant to get the original source, the same way that get_key() gets the
> key , whether it was allocated and stored in the source pointer or whether
> it was regenerated by a function. Being a getter, I named it get_source().
I use the get_ prefix for "true getters": those that read from format's
own memory (static variables, something the format had allocated, GPU
memory, etc.) I don't use this prefix for methods that merely convert
their parameter.
> >"struct salt *" passed to crypt_all(), so that it can do comparisons
>
> I do not understand the need for this, unless it is to work on multiple
> salts in parallel. If so, then do we need set_salt() ?
No, it is not to work on multiple salts in parallel. It is to allow
for comparisons of computed hashes against those loaded for cracking to
be performed within crypt_all() (inside a parallel region, on GPU, etc.)
This may already be done with caching, but that interface would make it
simpler and more explicit.
Note that "struct salt *" is not just the salt value. This struct has
bitmap, hash table, and linked list of hashes with that salt. So if a
format author feels like implementing custom hash comparisons, he/she
will be able to do so without extra magic.
You make a good observation about set_salt(). Yes, we may drop it.
When this interface is fully in use, it obsoletes cmp_all() too - but I
expect that only a minority of formats will do their own comparisons.
A format flag or crypt_all()'s return value will indicate whether
crypt_all() does the comparisons.
> >async crypt_all() (two blocks?) ability to exclude individual test
>
> Would this better be done in set_key() ?
You quoted two different items above and it sounds like you
misunderstood. Indeed, that very brief and cryptic to-do list was
initially for my own use only.
Anyway, I don't see how any of this may be done in set_key().
Thanks for your comments!
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.
