On Sun, Apr 22, 2012 at 4:54 AM, Marsh Ray <[email protected]> wrote: > On 04/22/2012 02:55 PM, Jeffrey Walton wrote: >> >> >> This might sound crazy, but I would rather have a NIST approved hash >> that runs orders of magnitude slower to resist offline, brute forcing >> attacks. > > > Well, that's what we have KDFs with a tunable work factor like PBKDF2 for. > > They're generally constructed out of HMAC or hash primitives like SHA-n and > the defender gets to personalize the work factor according to the cost he is > able to bear. The important thing for the security is that the attacker is > unable to find a way to perform that calculation faster than the defender. > Having a hash function that is as efficient as possible in both hardware and > software seems like a good way to approach that goal (and the folks who use > the hash with a healthy sized secret key won't complain about its speed > either. > > ... > > We can always take a fast function and iterate it until it is slow, but > making a slow function fast ought to be impossible. So having a 'fast as > possible but still secure' function as a primitive gives us more options. Aren't programs generally written to be fast and take advantage of things like locality of reference? I'd like to see a design that complete violates the design principal. Iterations in a KDF would then be icing on the cake.
Plus, its hard to balance iterations with security when the workforce is mobile and the attacker gets to perform an offline attack on a desktop. STRONGER KEY DERIVATION VIA SEQUENTIAL MEMORY-HARD FUNCTIONS, www.bsdcan.org/2009/schedule/attachments/87_scrypt.pdf. Jeff _______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
