Date: Wed, 8 Apr 2015 15:56:58 +0300 From: Solar Designer <solar@...nwall.com> To: john-dev@...ts.openwall.com Subject: Re: bechmark versus self-test Claudio, magnum - On Sun, Apr 05, 2015 at 07:48:19PM -0300, Claudio Andr? wrote: > JtR should allow the format to set which ciphers in test should be > used to benchmark. Reason: > - work only with passwords of the same size/cost/whatever. > > https://github.com/magnumripper/JohnTheRipper/issues/1182 IIRC, during benchmarking we currently use only the first two test vectors' salt strings (we alternate them for the "many salts" benchmark), but potentially with all of the test vectors' plaintexts. So the requirement to "work only with passwords of the same [...] cost/whatever" is currently addressed by making those the first two in tests. As to "size", if it means plaintext password length, then yes, it appears we currently lack the ability to lock it to a fixed value. We do have the ability to benchmark separately for passwords shorter than some length and longer than it, but only when we're not also benchmarking for one vs. many salts - see the logic around params.benchmark_length in bench_set_keys(). I initially introduced this for the AFS format, which differs greatly for length up to 8 vs. longer (with longer being much faster). While we could add a length lock feature, I think it doesn't fully solve the problem with benchmarking some of the recent formats, especially the PHC finalists where caching potentially plays a great role. On a GPU, we should be benchmarking with tens of thousands of _different_ test vectors, not just repeat a few same suitable-length test vectors over and over. > A POC can be seen here: > https://github.com/claudioandre/JohnTheRipper/commit/cd2f01e7263f6bfbb8017767c59a6877923765a1 I have mixed feelings about this. If we introduce an extra field to each test vector, it better be a flags field where we can add more flags later if we need to. Also, I am not sure if the proposed mask* fields address the caching issue I mentioned above or not. We need to address this issue even for slow hashes where it doesn't make sense for the format to bother providing its own mask mode support. Will this mask be used with our generic mask support code in such cases? 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.