Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 13 Jan 2015 19:21:47 +0100
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: PRINCE

On 2015-01-10 06:40, magnum wrote:
> On 2015-01-09 17:16, Solar Designer wrote:
>> On Fri, Jan 09, 2015 at 05:02:02PM +0100, magnum wrote:
>>> I saw a couple of bugfixes a day so far, so it's not completely stable.
>>> We should try to keep it "mergable" in one way or the other. At least
>>> refrain from large rewrites unless necessary. For example, we should
>>> #ifdef out unneeded code blocks instead of dropping them.
>>
>> Right, or alternatively we reimplement and then maintain our own code,
>> and submit it back to hashcat project.  Maybe later. ;-)  I think the
>> dependency on GMP could/should be avoided, e.g. in favor of "double"
>> (like our charset.c uses it) or in favor of saturation at 2^64-1.

FWIW I did a quick and dirty test today with dropping GMP and using
gcc's __uint128_t extension just to see what performance it would get.
That was trivial and the boost was pretty significant: 33% faster.

Internally gcc obviously does this using pairs of 64-bit words. I guess
we should add 128/64-bit versions of the 64/32 stuff in math.h instead,
for portability. Since I can use __uint128_t for testing I can probably
work out how to write the functions given enough trial and error :-)

Unless... Solar, you don't happen to have 128/64 code readily available?

magnum

Powered by blists - more mailing lists

Your e-mail address:

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