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 01:45:47 +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

Well, it’s not the salt per se, but the access pattern it generates.

Is there an attacker advantage if they have the ability to perform queries on the addresses generated by a unknown salt for a limited set of chosen password inputs?

I don’t recall if the PHC analysis considered this question explicitly for those functions with password-derived access patterns.

It’s probably a moot point for a couple of reasons:
* It doesn’t sound like we’re actually contemplating a function with a password-derived access pattern side channel, and
* The salt is not a capital-S Secret, by definition, so we’re forbidden from reasoning about it as if it were, even if hopefully it is.


-          Marsh


From: Bill Cox [mailto:waywardgeek@...il.com]
Sent: Wednesday, June 24, 2015 6:18 PM
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Why protect against side channel attacks

On Wed, Jun 24, 2015 at 5:55 PM, Marsh Ray <maray@...rosoft.com<mailto:maray@...rosoft.com>> wrote:
Again, these cache timing side channels tend to leak the salts too.

How?  In most cases, salt never leaves the authentication servers and associated storage.  The salt is hashed/shredded before unpredictable addressing begins.

Content of type "text/html" skipped

Powered by blists - more mailing lists