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  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, 23 Jan 2014 21:07:43 -0500
From: Bill Cox <>
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?


Powered by blists - more mailing lists