[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sun, 25 Oct 2015 22:50:23 +0100
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: db built from test vectors
On 2015-10-19 23:40, magnum wrote:
> On 2015-10-19 22:40, Solar Designer wrote:
>> On Mon, Oct 19, 2015 at 12:57:10AM +0200, magnum wrote:
>>> Since July, we always pass the real db to reset() if we have one. This
>>> was added for Agnieszka. With the above we could pass the fake db when
>>> we don't have any db. I guess we also need to pass db->salts in all
>>> crypt_all() calls - or perhaps only in benchmark. If we do so in
>>> self-test before a real crack run, we probably need to reset(fake db)
>>> before self-tests and reset(real db) after it. But that may collide with
>>> Agnieszka's needs, I'm not sure.
After some experimenting with code alternatives I think we should always
pass a "test vector db" for self-tests and benchmarks, and always pass
db-salts to crypt_all. The alternatives end up confusing and hacky.
If someone (eg. Agnieszka) need access to the real db at first call to
reset() (before self-test), we could simply add a pointer to the db
struct, eg. db->real:
If db->real == NULL, we don't have a real db (this is a --test run).
If db->real == db, this db *is* the real one.
I believe this would satisfy any needs.
>> This would be a change to how the formats interface is defined, as IIRC
>> it would go against what the comments in formats.h currently say.
>
> I think it wouldn't: Both for reset() and crypt_all(), it says "may" be
> NULL before self-test or benchmark. Though if we end up always passing a
> "fake db" before self-test, we should definitely say so for clarity.
If we go with my current ideas we should rephrase. Neither reset or
crypt_all will ever get a NULL pointer.
magnum
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.
