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.
An example of how *not* to do this is the old DES-based unix crypt()
function. DES was designed for hardware, so it's much slower in software
(where the defender runs it). They changed a few bits in the algorithm
in the hope that would remove the advantage of an attacker using the
available hardware for proper DES. But it turned out that the attacker
can use a much faster bitsliced implementation for software cracking, or
even FPGAs, and these optimizations are not available to the defender.
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.
- Marsh
_______________________________________________
cryptography mailing list
[email protected]
http://lists.randombit.net/mailman/listinfo/cryptography
