[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1340785002.74716.YahooMailNeo@web161306.mail.bf1.yahoo.com>
Date: Wed, 27 Jun 2012 01:16:42 -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 agree with you that openmp tuning is premature at this stage. Also I did not look seriously into openmp (though I started with it yesterday) but as mentioned by you that speedups are not impressive, I will also look in that with priority.
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). It thus is causing overhead in both single and many salt cases. 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. From crypt_all(), MD4 computation and setup_des_key() can be removed and put in mschapv2_set_key(). generate_output() is required before cmp_all() so i think we cannot take it out from crypt_all.
Cheers,
Deepika
________________________________
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Sent: Tuesday, June 26, 2012 6:32 PM
Subject: Re: [john-dev] mschap-v2 conversion
On Tue, Jun 26, 2012 at 10:06:47AM +0200, magnum wrote:
> Solar may respond much better when he gets some more time.
I'm sorry, but my opinion is that tuning OpenMP performance with the
current early/experimental bitslicing implementation for this format is
premature.
Notice that the speedup from bitslicing without OpenMP is quite low,
compared to what we're seeing for purely DES formats (much higher
speedup there). I guess this might be because of the uses of MD4 and
the conversions to/from bitslice representation, but that does not
explain the low speed for the "many salts" case (the uses of MD4 are in
key setup only). We need to seriously look into this and see what can
be done about it. That may be a higher priority than premature
optimization of OpenMP builds.
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.
