lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 25 Jun 2015 18:52:45 +0000
From: Marsh Ray <maray@...rosoft.com>
To: "discussions@...sword-hashing.net" <discussions@...sword-hashing.net>
Subject: RE: [PHC] Why protect against side channel attacks

From: Ben Harris [mailto:ben@...rr.is]
> And based on my experience working in companies, security policies
> are rarely so good that side channel attacks make up a large fraction
> of your risk level.

Things are changing with cloud. It’s the biggest shift in business computing I’ve seen since the personal computer. Shared CPU multi-tenancy is the new norm.


-          Marsh


From: Ben Harris [mailto:ben@...rr.is]
Sent: Thursday, June 25, 2015 7:54 AM
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Why protect against side channel attacks


On 25 Jun 2015 10:36 pm, "Krisztián Pintér" <pinterkr@...il.com<mailto:pinterkr@...il.com>> wrote:
>
> On Thu, Jun 25, 2015 at 4:16 PM, Ben Harris <mail@...rr.is<mailto:mail@...rr.is>> wrote:
> >> secret salt disables server relief
> >
> > You could have the client send
> > the password and the server reply with hash(password, salt) which the client
> > then does stretching on.
>
> i guess it would, but adds one more round of communication, and also
> removes the benefit of not needing the password ever leave the client.

The client needs to request the salt either way, so it isn't saving a round.

> all this hassle just to be able to use something that should not be
> used in the first place anyway.

I've always been on the cache-independent bandwagon, I'm just feeling that some of these arguments against cache-dependent candidates are getting a little close to FUD.

Performance efficiency
Data independence
Time-space-area hardness

None of the candidates give all three, it seems like we can only get two. And based on my experience working in companies, security policies are rarely so good that side channel attacks make up a large fraction of your risk level.

Content of type "text/html" skipped

Powered by blists - more mailing lists