Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 26 Jun 2012 00:16:12 -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,

I have few questions about mschap mentioned below:


1) I want to know the meaning of Thread_ratio and how the values of Thread_ratio and Max_keys_per_crypt are being decided? Is it fixed by you or is being decided based on some factor?

#define MIN_KEYS_PER_CRYPT    1
#define THREAD_RATIO        256
#ifdef _OPENMP
#define MAX_KEYS_PER_CRYPT    0x10000
#else
#define MAX_KEYS_PER_CRYPT    THREAD_RATIO
#endif


2) Without openmp: With openssl des, Thread_ratio (256) keys were read and used for encryption at a time. But with bitsliced des at a time only DES_BS_DEPTH keys can be used, so whether I should change the MAX_KEYS_PER_CRYPT parameter to DES_BS_DEPTH (which I have done for now in my patches) or I should keep it to Thread_ratio but process des_bs_depth keys at one go?

3) With openmp: For openmp Max_keys_per_crypt is 16 according to #define value, also in init() n is set to MAX_keys_per_crypt if greater than that. According to my understanding, this means that16 keys will be read and used at a time and thus bitslicing and openmp will not give any benefit as only 1 core will be in use with only 16 out of DES_bs_DEPTH layers being used. Therefore, this parameter needs change. Correct me if i am wrong.
 
int n = MIN_KEYS_PER_CRYPT * omp_get_max_threads();
if (n < MIN_KEYS_PER_CRYPT)
       n = MIN_KEYS_PER_CRYPT;
if (n > MAX_KEYS_PER_CRYPT)
       n = MAX_KEYS_PER_CRYPT;
pFmt->params.min_keys_per_crypt = n;
n = n * (n << 1) * THREAD_RATIO;
if (n > MAX_KEYS_PER_CRYPT)
      n = MAX_KEYS_PER_CRYPT;
pFmt->params.max_keys_per_crypt = n;
 
Cheers,
Deepika


________________________________
 From: deepika dutta <deepikadutta_19@...oo.com>
To: john-dev@...ts.openwall.com 
Sent: Tuesday, June 26, 2012 11:24 AM
Subject: Re: [john-dev] mschap-v2 conversion
 

hi, thanks for testing the patch, I will look into the openmp related details in the code and make the next patch fully functional (atleast for generic build for now). 
 Cheers,
Deepika


________________________________
 From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com 
Sent: Tuesday, June 26, 2012 3:51 AM
Subject: Re: [john-dev] mschap-v2 conversion
 
On 2012-06-25 21:30, deepika dutta wrote:
> I have done the change for key (xoring it with 0x80) before giving to
> DES_bs_set_key(), now it passes the test suite cases without any
> failure. The updated patch is attached.

I trust you about the Test Suite so did not check now. But something seems to be amiss with OMP:

Jumbo-5:
Benchmarking: MSCHAPv2 C/R MD4 DES [mschapv2]... DONE
Many salts:    2330K c/s real, 2330K c/s virtual
Only one salt:    1570K c/s real, 1570K c/s virtual

Benchmarking: MSCHAPv2 C/R MD4 DES [mschapv2]... (2xOMP) DONE
Many salts:    4200K c/s real, 2121K c/s virtual
Only one salt:    2717K c/s real, 1372K c/s virtual

Bitslice:
Benchmarking: MSCHAPv2 C/R MD4 DES [DES_BS_MSCHAPv2]... DONE
Many salts:    4488K c/s real, 4488K c/s virtual
Only one salt:    2280K c/s real, 2280K
 c/s virtual

Benchmarking: MSCHAPv2 C/R MD4 DES [DES_BS_MSCHAPv2]... (2xOMP) DONE
Many salts:    2946K c/s real, 1480K c/s virtual
Only one salt:    2077K c/s real, 1044K c/s virtual


The very last benchmark of the above indicates a bug: "Virtual" for OMP should ideally be close to the one for non-OMP. And real should ideally approach 2x virtual. In any case it should not be slower than non-OMP.

Also, for your next patch I think it's time you add a copyright notice like explained in http://openwall.info/wiki/john/licensing

magnum
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.