Re: Time Invariant String Comparison

[William Ahern <william@...>]

On Mon, Jan 20, 2014 at 02:40:35AM -0430, Andres Perera wrote:
<snip>
> But real world tools employ KDF-augmented password over keys as a
> two-factor auth mechanism, in essence recognizing that the two
> complement rather than replace each other. See TrueCrypt, OpenBSD
> CRYPTO discipline for softraid, and the previously cited OpenBSD SSH.
> 

Once upon a time using ciphers in CBC mode was considered the gold standard.
That was before padding attacks were realized.

Key stretching is slightly different because nobody seriously argues that
it's generically secure--like they did CBC. It's highly dependent on
context. It's more a soft measure than a hard measure. By soft measure I
mean things like password entropy estimators or CAPTCHA barriers. These
things aren't in the same domain as hard cryptographic primitives.

If hard cryptographic primitives with generic, rigorous proofs can fail, why
should I put much stock in soft measures? Especially ones that depend on
highly perishable assumptions about how much compute power my attacker has?

And I really couldn't care what other people use or say. I've been
implementing cryptographic protocols for almost 15 years. While I'm
certainly not a cryptographer, I'd like to think I have a learned
comprehension of things. And while I'd be happy to be disabused of my
opinions, you haven't provided any substantive arguments. All I've seen so
far are blog posts reciting cargo cult points (which instigated my post) and
documentation asserting something about "increased resistence". I never said
that key stretching doesn't make an attacker's job harder; I said that it
doesn't make it hard enough in the real world to provide any substantial
security, particularly when compared to other ways to spend one's precious
time.

Here's a blurb from the scrypt webpage:

	We estimate that on modern (2009) hardware, if 5 seconds are spent
	computing a derived key, the cost of a hardware brute-force attack
	against scrypt is roughly 4000 times greater than the cost of a
	similar attack against bcrypt (to find the same password), and 20000
	times greater than a similar attack against PBKDF2.

Who in their right mind would allow their website authentication system to
spend 5 seconds (an eternity!) hogging a CPU? Especially when you could
instead mandate passwords just three or four characters longer for the same
benefit and without crippling your throughput?

Anything over a millisecond is already too long for real websites. At that
point, the differential between scrypt and braindead SHA256+salt is so low
in real terms that you've hardly inconvenienced an attacker doing a
dictionary attack on user passwords. On a database he _already_ stole, mind
you, which should be your real concern!