[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.11.1505041420440.939@debian>
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