[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <724d0b27b6c168347d2ff1f234d0ee99@smtp.hushmail.com>
Date: Fri, 30 Jan 2015 02:04:50 +0100
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: PRINCE
On 2015-01-09 17:16, Solar Designer wrote:
> On Fri, Jan 09, 2015 at 05:02:02PM +0100, magnum wrote:
>> Cool. I already created an issue for it in
>> https://github.com/magnumripper/JohnTheRipper/issues/1011
>
> Great!
>
>> 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 here's the status on PRINCE:
- Sc00bz contributed significant speedup and bug fixes. It's now about
as fast as mask mode and "--skip" (which we use for resume) went from
super-slow to incredibly fast.
- I contributed dupe-checking (based on unique.c), several improvements
to memory use (including a simplified malloc_tiny()) and a nefarious
mpz_int128.h header that "emulates" the needed parts of GMP using
saturating __int128 macros. These are fast, Atom ditched GMP in favor of
this but he still keeps the code in GMP "syntax" which is required for
32-bit builds (even though he doesn't seem to have realized that detail
yet).
The PRINCE mode added to bleeding-jumbo is still the pristine code from
upstream but with a bunch of #ifdef JTR_MODE .. #endif macros added.
Some JtR-specific features:
- Our autoconf will use int128 if available, else GMP, and failing that
the mode will be disabled.
- We obviously have support for resuming, node/fork and such things.
- Encoding support (no performance loss except for initial load).
- Loopback support.
- Optional mmap() support (upstream still only reads from stdin).
- Rules support.
The rules support is very slow since it runs each word through all rules
instead of vice versa. An easy fix would be running the mode's
inner-most loop (I think it's typically in the order of 64K words)
through all rules but this would probably force me to let go of easy
upstream merges so that's deferred for now.
BTW that fake-GMP header should be enhanced to use 64x64 structs when
int128 is not available, but that's for a rainy day.
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.
