[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20150126000924.GA4843@openwall.com>
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.
