Date: Sun, 18 Jan 2015 19:58:24 +0530 From: Sayantan Datta <std2048@...il.com> To: john-dev <john-dev@...ts.openwall.com> Subject: Redesign Self-test for implementing compare on device. Hi Solar, magnum, >From format.h /*... * Returns the last output index for which there might be a match (against the * supplied salt's hashes) plus 1. A return value of zero indicates no match. * *Note that output indices don't have to match input indices (although they** * may and usually do). * The indices passed to get_key(), get_hash(), * cmp_one(), and cmp_exact() must be in the 0 to crypt_all() return value * minus 1 range, although for infrequent status reporting get_key() may also * be called on indices previously supplied to set_key() as well as on indices * up to the updated *count minus 1 even if they're beyond this range. * The count passed to cmp_all() must be equal to crypt_all()'s return value. * *If an implementation does not use the salt parameter or if salt is NULL** > * (as it may be during self-test and benchmark), the return value must always > * match *count the way it is after the crypt_all() call.* * The count is passed by reference and must be updated by crypt_all() if it * computes other than the requested count (such as if it generates additional * candidate passwords on its own). The updated count is used for c/s rate * calculation. The return value is thus in the 0 to updated *count range. */ > > First, when salt is NULL, why does the return value of crypt_all() has match *count the way it is after crypt_all() call ? Can't we remove this restriction ? Here's the previously discussed idea on this issue: https://github.com/magnumripper/JohnTheRipper/issues/1030#issuecomment-70404396 Second, alhough the specification says output indices don't have to match input indices, the problem is we're not strictly following this during self test. During self test we have this restriction that the length of the input key(set using set_key()) must be equal to the length of the return value of get_key() for same indices. Regards, Sayantan Content of type "text/html" skipped
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.