[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4cb97510b6421cbeba3a9fde97f7a90e@smtp.hushmail.com>
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
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
