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.