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  linux-hardening  linux-cve-announce  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: Mon, 4 May 2015 14:37:48 +0200 (CEST)
From: Stefan.Lucks@...-weimar.de
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Maximising Pseudo-Entropy versus resistance to Side-Channel
 Attacks

On Thu, 30 Apr 2015, Solar Designer wrote:

> On Thu, Apr 30, 2015 at 02:43:45PM +0200, Stefan.Lucks@...-weimar.de wrote:

>> Except that there is no law that requires defenders to publish their
>> password files. Given past experience, it would be unwise for the defender
>> to assume the password file will never be compromised.

[...]

> While you're mostly correct, you're somehow omitting important detail.
> As discussed before, salting may defeat side-channel attacks on password
> hashes, as long as the salts are not known/predictable by the attacker.
> In your example, "without knowing the password file, Mallory would"
> typically also not know the salts, so would not be able to mount a
> side-channel attack.

Agreed. I should have been more precise here.

Having spent much of my academic life on performing cryptanalysis, i.e., 
on attacking schemes, the idea to rely on the randomness of the salt 
doesn't quite convince me, though. I understand the "random" salt mostly 
as a nonce, i.e., a value that is supposed to never repeat. You can safely 
use a low-quality entropy source, such as your system clock, to derive 
your "random" values. You can even use a counter, together with (a hash 
of) your sever ID.

As long as the salt does not repeat, your password hashing scheme should 
be OK. (And even very rare exceptions of the same salt for two independent 
passwords would not harm too much.) But to defeat the kind of side-channel 
attacks we talk about, the salt would now have to be unpredictable for the 
adversary. I.e., you would need a high-quality random source for to 
generate your salts -- pretty much the same thing you would use for 
generating secret keys.

(Well, not quite. But close. You might be happy with, say, a 80-bit enropy 
salt, where you would expect your 128-bit key to have full 128-bit 
entropy.)

> However, a relevant question is: are we focusing on avoiding unlikely 
> yet potentially fatal special cases, or are we trying to reduce the 
> percentage of passwords that will get cracked in a more likely case?  I 
> expect that answers will vary.

Agreed. The tradeoff, potentially a few more bits of pseudo-entropy for 
all cases versus an almost total loss for some cases. This is precisely my 
reason I wanted to discuss this.

> Right.  However, garbage collector attacks do matter for KDF use,
> perhaps more so than for password hashing use.

Fair enough.

Stefan

------  I  love  the  taste  of  Cryptanalysis  in  the morning!  ------
uni-weimar.de/de/medien/professuren/mediensicherheit/people/stefan-lucks
--Stefan.Lucks (at) uni-weimar.de, Bauhaus-Universität Weimar, Germany--

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ