Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 21 Jun 2012 23:20:39 +0400
From: Solar Designer <>
Subject: Re: formats interface enhancements

On Thu, Jun 21, 2012 at 09:44:21AM -0500, jfoug wrote:
> >From: Solar Designer []
> >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!


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.