Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Wed, 26 Oct 2005 17:26:30 +1000
From: "David Luyer" <david@...er.net>
To: <john-users@...ts.openwall.com>
Subject: Patch: Improved raw-md5 and new format (Post.Office MD5)

I'd like to submit the attached patch to John the Ripper.
Please feel free to include the patch on the website or in
any future version (it is released under the terms of GPL
version 2).

The patch:

1.	Improves the performance of raw-md5 around 20% compared
	to the version currently on the website. [1]

2.	Implements the Post.Office MD5 crypt format, which may
	be found in Post.Office and in LDAP directories migrated
	from Post.Office (for example, OpenWave and qmail-ldap
	can support this crypt format).

For more details, read the patch.

Tested on little-endian 32-bit and big-endian 64-bit.

David.

[1]	Example - Athlon64 3500 in 32-bit mode
		(linux-x86-64-mmx)

		Before: [2]
			2409K c/s real, 2419K c/s virtual
			2410K c/s real, 2420K c/s virtual
			2437K c/s real, 2457K c/s virtual
			2454K c/s real, 2459K c/s virtual
			2398K c/s real, 2408K c/s virtual

		After: [3]
			2808K c/s real, 2813K c/s virtual
			2898K c/s real, 2910K c/s virtual
			2959K c/s real, 2971K c/s virtual
			2947K c/s real, 2959K c/s virtual
			2991K c/s real, 3003K c/s virtual

		Speedup: 20.5%

	Example - UltraSPARC-IIIi 1002MHz in 64-bit GCC mode
		(solaris-sparc64-gcc)

		Before:
			822951 c/s real, 822951 c/s virtual
			825384 c/s real, 825384 c/s virtual
			822242 c/s real, 822242 c/s virtual
			823006 c/s real, 823006 c/s virtual
			826447 c/s real, 826447 c/s virtual

		After:
			967705 c/s real, 971583 c/s virtual
			966351 c/s real, 966351 c/s virtual
			968198 c/s real, 968198 c/s virtual
			966123 c/s real, 966123 c/s virtual
			968405 c/s real, 968405 c/s virtual

		Speedup: 17.5%

[2] Earlier "before" test runs were at 2300K c/s, however when I
    ran this again to get five times they were all higher.

[3] Earlier "after" test runs were at 3100K c/s to 3200K c/s
    however this was due to an error in the memset() call
    which didn't show up as the memory was usually already zero.
    It may be possible to improve performance towards these
    levels if the memory can be zero'd faster than it is by
    memset(), for example perhaps a memcpy from memory which
    is already zero?

[ CONTENT OF TYPE application/x-gzip SKIPPED ]

Powered by blists - more mailing lists

Your e-mail address:

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