phc-discussions - Re: [PHC] cache timing attacks (Re: [PHC] Initial multiply-compute-hardened Catena-3 benchmark)

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]

Message-ID: <CAOLP8p631yEPLixtVwDYMnz6RsJQM6UPnfxtcjzpYBKAodY7CA@mail.gmail.com>
Date: Thu, 23 Jan 2014 21:07:43 -0500
From: Bill Cox <waywardgeek@...il.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] cache timing attacks (Re: [PHC] Initial multiply-compute-hardened
 Catena-3 benchmark)

If there is a machine generated true random secret of even 128 bits,
the attacker might as well pack it up and go home.  Any password
protected by that is secure against guessing in off-line attacks.  The
attacker would be better off repeatedly querying the server.  Keeping
the salt secret is just like giving up on salt and using it instead
like a Blakerypt style "session key", which is random bits meant to be
secret.  I think salt has an important function on it's own, and we
should reserve a separate place for a password dependent secret known
only to the server.  For example, salt can be transmitted to clients
for server relief, but session keys (probably a bad name) should not
be sent anywhere.

If there were two changes I could make to an enhanced PHC function
prototype, it would be adding a session key, and a flag saying it's OK
to clear the password before filling memory.  Is there a better word
for describing secret password-dependent keys than session keys?

Bill