[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 9 Jan 2015 19:16:09 +0300
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: PRINCE
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.
> > So, anyone wants to integrate this code into -jumbo as a new cracking
> > mode (which it is)?
>
> Unless someone else (read Jim :) beats me to it, I will.
Thanks!
> On a side note I haven't looked at the code at all yet but I'm curious
> about this mode vs. GPU generation. Perhaps the hotter parts can reside
> on GPU? That would be awsome. If it's worthwhile at all I'm sure Atom
> will implement it soon.
I think this is do-able and reasonable.
> > There's a dependency on GMP, so (as currently implemented) this mode
> > should only be included if GMP is found by the configure tests (we
> > already have a test for it, for SRP).
>
> Yes, we'll have autoconf take care of that. The SRP formats can
> optionally do without GMP with some speed penalty, perhaps we can
> implement that later.
I wouldn't even expect any speed penalty for PRINCE if we move it off
GMP - I'd expect slight speedup or no measurable change.
Alexander
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.
