[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sun, 19 Aug 2012 16:14:41 -0500
From: "jfoug" <jfoug@....net>
To: <john-dev@...ts.openwall.com>
Subject: RE: int crypt_all(count, salt)
>From: magnum [mailto:john.magnum@...hmail.com]
>> I think I'll get something like this into CVS eventually - I'm not
>> sure how soon that will be. Do you want to have this in bleeding,
>> even though you'll need to replace it with whatever gets committed to
>> CVS later?
>
>Maybe not. I'm mostly curious about done() and the faster self-test
>right now.
I would also be interested in separation of self-test data, and benchmark
data. That way, we could keep the bench timings normalized from build to
build, but start adding a lot more into the self test vectors, on some of
the formats. There are many formats now, which have multitude of different
complexity, and even types of hashes. If they have historical bench timings
with one setup, and we start to add new vectors (which we should), then
there is not a normalized comparison from version to version on timings.
But not adding 'test' strings is not a good thing either. I know this has
been kicked around a little in the past. I am not sure if there were any
official plan on implementation of this yet.
It may be as simple, as a 2nd null terminated array of fmt_test data. That
array would only be used during the test phase, and not in the bench. That
way, we could add many new items there, but keep the bench normalized from
version to version.
Jim.
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.
