Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 9 Jan 2015 19:44:54 +0300
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: PRINCE

On Fri, Jan 09, 2015 at 05:20:53PM +0100, Frank Dittrich wrote:
> On 01/09/2015 05:16 PM, Solar Designer wrote:
> > 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.
> 
> But, depending on implementation, you would get different candidate
> sequences, right?

Yes, if we use "double" we might get different results from hashcat
pp's, although I find this unlikely (probably not in the first 2^52
candidates).  If we use integers capped at 2^64-1 or so, I think we'll
even more likely get the same results in practice, because we won't be
trying that many candidates in practice.  (Or maybe I misunderstand
how/why GMP is used there?)

If this stuff is ever implemented on GPU as magnum suggests, then
perhaps proper sorting beyond 2^64 would become relevant.  Perhaps we
can use something custom like 96-bit integers there, or perhaps this
portion of pp would stay on host.

> That means, you can't start a session with a john build that has OMP
> support, interrupt it, and resume with a build lacking OMP support.

I guess you mean GMP, not OMP?

If we remove the dependency on GMP, then I see no reason for us to have
pp use GMP in any build, even if GMP is available.

> Generating the same candidate sequence as hashcat (given the same input)
> would be desirable.

Agreed.

Alexander

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ