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.