[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 27 Jun 2012 02:54:35 -0700 (PDT)
From: deepika dutta <deepikadutta_19@...oo.com>
To: "john-dev@...ts.openwall.com" <john-dev@...ts.openwall.com>
Subject: Re: mschap-v2 conversion
Hi solar,
I am in some confusion, you wrote that "but that does not explain the low speed for the "many salts" case (the uses of MD4 are in key setup only)", where you want to say that since MD4 is in key setup only and since for many_salt case, key setup is not performace critical therefore speedup should be high. But what is happening in mschapv2 is that in mschapv2_set_key() ( which is called from bench_set_keys()) following is being done only (keys are being copied to saved_plain[]).
saved_len[index] = strlen(key);
memcpy(saved_plain[index], key, saved_len[index] + 1);
keys_prepared = 0;
But md4 calculation is being done in mschapv2_crypt_all() which happens in both single and many salts cases (i debugged and confirmed). So how is keys_prepared flag playing any role here in avoiding this computation? This means that apart from above three lines of code, same thing is happening in single salt and many salt and thus the difference in benchmark result for both should not be very high.
Correct me wherever i am wrong.
Cheers,
Deepika
________________________________
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Sent: Wednesday, June 27, 2012 2:07 PM
Subject: Re: [john-dev] mschap-v2 conversion
On Wed, Jun 27, 2012 at 01:16:42AM -0700, deepika dutta wrote:
> From what I have understood, benchmarking for many salts case measures time for 'setting salt', 'crypt_all' and 'cmp_all' wheres for single salt also includes 'set_keys'. The various performance overheads therefore are:
>
> 1. In set_salt: Conversion of 'challenge' to bitsliced form 'Plaintext'.
> 2. In crypt_all: MD4 computations for key setup key are being done here (and not in mschapv2_set_key() as i belive you maybe assuming).
Correct so far. I was aware of this implementation detail, but thanks
for mentioning it anyway.
> It thus is causing overhead in both single and many salt cases.
No, this is avoided with the keys_prepared flag.
> The other overhead is of generate_output() which converts from bitsliced form to output[] and also of setup_des_key().
>
> I don't think we can remove overhead from set_salt(), we have to convert to bitsliced plaintext.
We can perform this conversion in get_salt() instead, which is not
performance-critical. If the conversion is fully moved like that, the
salt size would be pretty large, though. It might be quicker (due to
smaller reads) to do DES IP in get_salt(), but expansion of bits to
words (and only it) in set_salt().
> From crypt_all(), MD4 computation and setup_des_key() can be removed and put in mschapv2_set_key().
They should be kept inside crypt_all() in order for us to be able to
parallelize them with OpenMP later. However, they should be protected
from unnecessary recomputation with the keys_prepared flag. IIRC, this
is currently done for MD4, but not for DES key setup - we should do it
for both.
> generate_output() is required before cmp_all() so i think we cannot take it out from crypt_all.
generate_output() should be avoided entirely. See how DES_bs_cmp_all()
is implemented.
Then, for the case when cmp_all() is not used but one of the get_hash*()
functions is, you do in fact need to extract a few individual bits - but
there are already DES_bs_get_hash_*() functions that do that, and you
don't need to do it in crypt_all().
Thanks,
Alexander
Content of type "text/html" skipped
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.
