Date: Mon, 26 Jan 2015 03:09:24 +0300 From: Solar Designer <solar@...nwall.com> To: john-dev@...ts.openwall.com Subject: Re: Redesign Self-test for implementing compare on device. On Sun, Jan 25, 2015 at 03:05:14AM +0100, magnum wrote: > On 2015-01-18 15:28, Sayantan Datta wrote: > > 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 > > Perhaps that wording in formats.h is merely reflecting the current > self-test's requirement? I can't see any reason why we couldn't lift > that restriction. Can you? I asked Sayantan to bring this up on the ML > to avoid us making decisions you would later reject or dislike. We're talking about: * 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. IIRC, it's as follows: Case 1: "an implementation does not use the salt parameter". This suggests that the implementation of crypt_all() does not compare computed vs. loaded hashes (since it'd normally access the latter via the salt parameter), leaving that for cmp_*(). If so, it can't reasonably return a value lower than *count, because it can't eliminate any of the candidates it computed hashes for (and it computed *count hashes). Case 2: "salt is NULL". This is just for the self-test to test that crypt_all() does indeed return something reasonable, as opposed to e.g. forgetting to return anything (like older formats would do, since crypt_all() was previously "void"). For case 1, we may adjust the wording to say "an implementation does not compare computed vs. loaded hashes" in place of "an implementation does not use the salt parameter". For case 2, we may replace that requirement and test with a more relaxed test that the returned value is in the 0 to *count range. We don't need to mention the special case of salt == NULL then, because that range applies in all cases. We also don't need to mention this test in that comment at all. It's just one of the requirements already stated in there. However, I am concerned that in many cases the return value will just happen to be in range (e.g. a 0 return is fairly likely on a simple "return;" without a value). So the test for the return value will become less effective. Maybe we just have to accept that. 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.