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.