Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 27 Apr 2014 22:47:43 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Re: mmap()

On 2014-04-27 15:44, jfoug@....net wrote:
> From an offlist request.  I thought this might be good information
> for the list, to see how cygwin, which is still limited to the diskIO
> constraints of Win32 (which SUCK) behaves. It does work with magnums
> mmap port (had to adjust some defines in the include section, but it
> was no big deal).  I have no idea how real-world ready this code is
> at the moment.  magnum has this in a separate tree in git, so I
> assume it is still being actively developed, and not ready for real
> world.

Actually I was planning to merge it as soon as we know Windows is 
working. I presume all other targets have mmap().

> Testing with mmap:
> Loaded 1 password hash (Raw-MD5 [MD5 128/128 SSE2 12x])
> jucarius         (u0-RawMD5)
> 1g 0:00:00:02 DONE (2014-04-27 08:09) 0.4452g/s 3320Kp/s 3320Kc/s 3320KC/s 1616888..jucarius
>
> Testing with bleeding (no memory buf)
> 1g 0:00:00:04 DONE (2014-04-27 08:14) 0.2157g/s 1609Kp/s 1609Kc/s 1609KC/s 1616888..jucarius
>
> Testing with bleeding (memory buf large enough to hold entire file)
> 1g 0:00:00:01 DONE (2014-04-27 08:17) 0.5341g/s 3983Kp/s 3983Kc/s 3983KC/s 1616888..jucarius

Note that the last test should be done with the mmap version too because 
the mmap-branch fills that array using the memory map and "mgetl()" 
instead of fgetl(). So it will speed up the "array buffer" too!

> With rules:  (Note, input hash busted, so the full rules would run)
>
> Testing with mmap:
> 0g 0:00:01:04 DONE (2014-04-27 08:21) 0g/s 1950Kp/s 1950Kc/s 1950KC/s Ddiinnkkoing..Jucariusing
> Testing with bleeding (no memory buf)
> 0g 0:00:03:56 DONE (2014-04-27 08:27) 0g/s 535200p/s 535200c/s 535200C/s Ddiinnkkoing..Jucariusing
> Testing with bleeding (memory buf large enough to hold entire file)
> 0g 0:00:00:51 DONE (2014-04-27 08:22) 0g/s 2479Kp/s 2479Kc/s 2479KC/s Ddiinnkkoing..Jucariusing

Same applies here.

Here are my latest test results. OSX has similar figures. All are from 
attacking a single uncrackable NT hash with Rockyou. The "x4" means 
--fork=4 and "+buf" means "-mem=0" for array buffer.

Linux            rockyou      +rules   rockyoux4     +rulesx4
-------------+-----------+-----------+-----------+------------+--------------
bleeding       11475Kp/s    3161Kp/s   20488Kp/s    12441Kp/s
bleeding-buf   10625Kp/s    5864Kp/s    7828Kp/s    20139Kp/s
fgetl-sse      14202Kp/s    4004Kp/s   28688Kp/s    15314Kp/s
fgetl-sse+buf  10625Kp/s    5777Kp/s    5085Kp/s    20839Kp/s
mgetl          14344Kp/s    4484Kp/s   31014Kp/s    17084Kp/s
mgetl+buf         n/a       5831Kp/s      n/a       20866Kp/s
mgetl-sse      16117Kp/s    4445Kp/s   32789Kp/s    18375Kp/s
mgetl-sse+buf     n/a       5841Kp/s      n/a       21069Kp/s

The fgetl-sse is an experiment using same wordlist.c as in bleeding, but 
with fgetl() using Atom's fgets-sse2 code. The mmap code is faster than 
that. I'm experimenting with using SSE *with* mmap (not Atom's code) but 
since most words are shorter than 16 bytes it seems to be better using 
32-bit or even 8-bit stuff.

magnum

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ