Date: Thu, 7 Jun 2012 07:24:31 -0500 From: "jfoug" <jfoug@....net> To: <john-dev@...ts.openwall.com> Subject: RE: get_source() and bitmaps boost >From: magnum [mailto:john.magnum@...hmail.com] >Formats that has get_source() are currently: crc32, nt, nt2, raw-md5, >raw-sha1, raw-sha1_li and sapg, plus some or all dynamic formats, I >presume all of them. Other formats are even more unlikely to be affected >by any problems from the new code. In dynamic, right now, only dynamic_0 is get_source supported (raw-md5). Right now, it is controlled by adding 1 of 2 flags (one for a 32 byte MD5, and 1 for a 40 byte SHA1 source hash). Doing get_hash in dynamic, is not going to be as easy, as in other formats, especially for salted formats, and ESSPECIALLY for complex salted formats (say a salt, and user id, or a very complex salt like HDAA). Right now, it 'could' handle any non-salted format, with simple lower case characters. So, by simply adding the right flags, we easily could do this for: dynamic_0 dynamic_2 dynamic_3 dynamic_22 dynamic_23 dynamic_26 dynamic_29 dynamic_30 dynamic_33 dynamic_34 dynamic_1001 dynamic_1002 dynamic_1004 dynamic_1005 dynamic_1006 But this has not yet been done, or tested. The complexities that arrive when doing salted formats within dynamic, are many. First, a complex salt, can have the salt elements in any order. I may have to normalize this within prepare. Second, The usage of $HEX$ is optional (but may be required to encode certain salts). So, again, this may have to be normalized. HOWEVER, normalization of a $HEX$ type salt, would cause that to be the type written to the pot file. I am not sure that is what we would want. Also, there will be many nuances in loading any legacy .pot file lines, written prior to said change. When we get to the get_source() we have no idea what was used to build the original source string with. We do not know order, whether get_source should use HEX, etc. I simply dont have time I would need to invest in getting all of the issues worked out for salted dynamic formats at this time. With all of the added flexibility, comes much ambiguity, and a ton of complexity. Jim.
Powered by blists - more mailing lists
Powered by Openwall GNU/*/Linux - Powered by OpenVZ