phc-discussions - large salts (was: Let's not degenerate when if the PRF is too narrow for desired output)

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: <20130417153521.GA17391@openwall.com>
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