[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1360264868.32530.YahooMailNeo@web140906.mail.bf1.yahoo.com>
Date: Thu, 7 Feb 2013 11:21:08 -0800 (PST)
From: deepika dutta <deepikadutta_19@...oo.com>
To: "john-dev@...ts.openwall.com" <john-dev@...ts.openwall.com>
Subject: Re: mschapv2-bitsliced conversion
Hi, I am attaching a new patch which is tested to work on both 32 and 64 bit SSE2 linux OS. I have modified both x86-sse.S and x86-64.S.
I cannot say for sure that this will not break the build on other targets. I think someone should test this since I do not have those target machines. I will try to rectify any problems which arise due to this.
Regarding working on converting other formats, though I don't think it will be too difficult but I will inform you whenever I get ample time to devote on it :)
Cheers,
Deepika
________________________________
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Sent: Thursday, February 7, 2013 2:43 PM
Subject: Re: [john-dev] mschapv2-bitsliced conversion- openmp support
On 7 Feb, 2013, at 8:35 , Frank Dittrich <frank_dittrich@...mail.com> wrote:
> On 02/07/2013 04:47 AM, Solar Designer wrote:
>> On Wed, Feb 06, 2013 at 07:12:34AM -0800, deepika dutta wrote:
>>> Actually, I worked on coverting the DES_bs_crypt_plain(), which I had added to do single DES encryption, into SSE implementation. I have added this function into the x86-sse.S file. Since the code in this file was in assembly language, I tried some copy-pasting from previous code and added some assembly code myself to get the single DES encryption working. I compiled this program using linux-x86-64 option, everything is working fine and the latest banchmarks for bitsliced implementation are given below. You can test for yourself. The patch is attached.
I'm confused - isn't x86-sse.S only used for 32 bit SSE builds? For 64-bit it should be x86-64.S. Or did you do both? That would be awesome.
>> This is cool, but (un)fortunately we've just revised the MSCHAPv2 format
>> such that it does not depend on speed of DES encryption anymore - see
>> the "NetNTLMv1 and MSCHAPv2" thread in here. So I'm afraid there's no
>> point in introducing your changes to that format now (nor would they
>> apply to the revised code).
>
> But the changes should apply to the new mschapv2-naive format which
> basically is the renamed old mschapv2 format, intended for shorter
> cracking runs, because it loads hashes faster than the new mschapv2.
True, although it wouldn't be much benefit other than as a nice example of code - you'll only use the old naïve version for very short runs where the speed doesn't matter anyway.
Anyway, the thing that has stopped me from pulling the MSCHAPv2 BS patches into Jumbo is the fact they (so far) b0rked builds other than generic (and now linux-x86-64?). I haven't looked at this latest patch yet but I assume it still breaks some builds. There is no need to implement BS for every single target, but the changes need to be #ifdef'ed so that all builds pick code that works for it. Given that, I'll include it right away (even for mschapv2-naive).
Also, new patches should ideally be rebased upon the bleeding-jumbo branch on GitHub: https://github.com/magnumripper/JohnTheRipper/tree/bleeding-jumbo
magnum
Content of type "text/html" skipped
View attachment "john-1.7.9-jumbo-5-MSCHAPV2-BS-4.diff" of type "text/x-patch" (16704 bytes)
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.
