Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 7 Feb 2013 20:50:32 +0100
From: magnum <>
Subject: Re: mschapv2-bitsliced conversion

Thanks, I'll have a look at your patch within a week.


On 7 Feb, 2013, at 20:21 , deepika dutta <> wrote:

> 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 <>
> To: 
> 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 <> 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:
> magnum
> <john-1.7.9-jumbo-5-MSCHAPV2-BS-4.diff>

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.