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  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: Wed, 17 Apr 2013 19:35:22 +0400
From: Solar Designer <solar@...nwall.com>
To: discussions@...sword-hashing.net
Subject: large salts (was: Let's not degenerate when if the PRF is too narrow for desired output)

On Wed, Apr 17, 2013 at 08:00:55AM -0700, bitweasil Bitweasil wrote:
> > So unless you are storing a several kilobyte hash there is almost no
> difference in time.
> 
> "I'd tell 'ya what I'd do with a 3 character password.  4096 bytes of
> encryption key at the same time."

On a related note, large salts are actually a way to implement security
through obesity.  That is, the effect is in some ways similar to that of
Jeremy Spilman's "blind hashing", although his approach was different.
Unfortunately, they achieve little as it relates to targeted attacks on
individual accounts (if we have access, it is not hard to steal one
large salt out of many, as long as we know which one to steal).  They're
only of some (very limited) help against mass user database downloads.

I'd rather go for the "ROM on SSD" approach (a large lookup table used
during hash computation) instead of either "blind hashing" or the large
salts trick.  However, I guess on some systems implementing large salts
may be as simple as tweaking a configuration setting, so this might not
be too unreasonable despite of being of lower effectiveness as compared
to other known alternatives.

Alexander

Powered by blists - more mailing lists