Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20121008160031.GB8250@openwall.com>
Date: Mon, 8 Oct 2012 20:00:31 +0400
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: Password hashing at scale (for Internet companies with millions of users) - YaC 2012 slides

On Mon, Oct 08, 2012 at 06:44:03AM +0530, Sayantan Datta wrote:
> On Mon, Oct 8, 2012 at 1:24 AM, Solar Designer <solar@...nwall.com> wrote:
> > Now, the defender might in fact have some parallelism, due to multiple
> > nearly concurrent authentication attempts (for the same or different
> > target accounts).  In practice, this lets defenders benefit from
> > multiple CPU cores and SMT, but usually not from SIMD, nor from other
> > optimizations to be made within one thread (such as the instruction
> > mixing I mentioned).  Those optimizations are tricky and risky for
> > defenders, and they require synchronization of different authentication
> > attempts (delaying processing of some in order to process them in
> > parallel with others).  It is a lot better to design the hashing method
> > such that it has sufficient parallelism in it, and make use of that
> > parallelism for defense without having to combine processing for
> > different authentication attempts at a low level.
> 
> Why would the optimizations become risky for defenders?

Complexity goes against security.  Also, extra potential side-channels
get introduced.

> I mean , does/could
> those optimizations you mentioned give the attacker any added advantage?

With perfect design and implementation of the hashing method in use by
the defender, no - but perfection is not realistic.

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.