[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120722135921.GA20541@openwall.com>
Date: Sun, 22 Jul 2012 17:59:21 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: int crypt_all(count, salt)
myrice -
On Sun, Jul 22, 2012 at 08:59:05PM +0800, myrice wrote:
> I doubt this code in fmt_self_test_body, here is the diff part:
>
> - if (format->methods.crypt_all(index + 1, NULL) != index + 1)
> - return "crypt_all";
> + {
> + int count = index + 1;
> + if (format->methods.crypt_all(&count, NULL) != count)
> + return "crypt_all";
> + }
>
> We could change count in crypt_all and the return "matched count" may
> not the the same with the count passed in. So could we change != count
> to != index+1?
While the check above is broken (I was/am going to revise it when
implementing this for real), I think this shouldn't matter for your
work. The self-test assumes a 1-to-1 mapping between input and output
indices anyway, so you have to implement just that when crypt_all() is
called from the self-test - well, or disable the builtin self-test for
your experiments, but that's worse. The self-test also assumes that
get_key() returns exactly what was passed to set_key(). In order for it
to properly test get_key() in case the format modifies the keys or
generates additional ones, it'd need a way to know just what
modifications or additions are expected - e.g., we'd need to have
set_mask() first, which we don't yet have for your early experiments.
And we'd need to have unusual test vectors, with ciphertexts
corresponding to other than the originally specified plaintexts.
The check is broken not only in the way you describe (addressing which
would be insufficient anyway, as I explained), but also in that iff the
function modifies count, the behavior of the check is, as far as I
recall C sequence points, unspecified. I think there's a sequence point
right before the function call (when all the arguments are evaluated),
but not right after it. Thus, the check may be comparing against count
the way it was before the call or the way it is after the call,
according to a given C compiler's preference or whim on a given day.
As written, this is really meant to work only for the case when the
function does not modify count, and that is also for the more
fundamental reason described above.
Thanks,
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.
