[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150109164454.GA17041@openwall.com>
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
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
