Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 9 Jan 2015 19:16:09 +0300
From: Solar Designer <>
Subject: Re: PRINCE

On Fri, Jan 09, 2015 at 05:02:02PM +0100, magnum wrote:
> Cool. I already created an issue for it in


> 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.


> 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.


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.