[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <579b16b2dc0bb220af5d8142818d3bb9@smtp.hushmail.com>
Date: Mon, 19 Oct 2015 00:57:10 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: db built from test vectors
Solar,
https://github.com/magnumripper/JohnTheRipper/issues/1835
A problem with many GPU-mask formats is they need a lot of special
handling for the test/benchmark case (where we lack a db). I have added
this experimental function that creates a supposedly complete db from a
format's test vectors:
struct db_main *ldr_init_fake_db(struct fmt_main *format);
So we could have this in a format, or perhaps in benchmark_format():
if (!db) {
fake_db = 1;
db = ldr_init_fake_db(format);
}
(...)
if (fake_db)
ldr_free_fake_db(db);
I'm not yet sure about all details on how we should use this or what
more changes need be made to core code but I reckoned I should give you
a heads-up.
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.
Perhaps we should not change test/benchmark at all but instead use this
feature in format code as needed. Sayantan's formats could set a
format-global pointer to fake_db in reset(), and when crypt_all is
called with a NULL salt, we can use fake_db->salt instead.
We'll see where things lead. Perhaps you have some thoughts or ideas?
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.
