-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I also think that scrypt is going in the wrong direction. Yeah, sure,
it's chewing up memory as well as CPU time, but that's not a feature,
it's a bug. It means you have to be careful deploying it in a limited
environment and that includes virtual machines. It's gilding the lily.
scrypt is absolutely solving a real problem. You say that it costs
about $1.5 million to crack a PGP ZIP file with a 12-letter password
using EC2. The US intelligence budget last year was about $50 billion.
The NSA doesn't use EC2. Whatever password-cracking hardware they have
available, I'm sure they've spent more than $1.5 million on it, and
once it's built, the marginal cost of cracking one more password is
very low.
Let me try to explain this better.
The advantage is always to the attacker for being able to parallelize. All the
reasons you give are correct. However, the advantage is to the defender to do
something as simple as increase the size of your passphrase because that grows
exponentially.
The metric I showed was interesting because it's a real-world example of buying
a parallel computer with some real monetary metrics on it. You can scale that
metric however you want for whatever advantages or disadvantages you ascribe to
the attacker.
Let me do just that now with a gedankenexperiment and because we're talking
about The Government, we'll scale that $1.5M to crack a 12-character password
down to $1. Note again, we're talking about lowercase-only passwords and you
can improve the defender's job by using more than 26 characters.
How much does it cost to crack a 13-character password? That's easy -- $26.
So what about 14-characters? $676.
15 characters? $17576. By the way, using the original metric -- the $1.5M one
-- we're now at just about the *entire* US Intelligence budget.
At 21 characters, we are at a cost of $5,429,503,678,976. That's 5.4 trillion
dollars, which is the neighborhood of the entire recent economic meltdown. If
you want to argue, let's add one more character and end up with a cost of $141
trillion bucks.
25 characters? $2,481,152,873,203,736,576. That's 2.5 * 10^18. Or 2.5 million
trillion dollars. To reiterate once again, this is even granting The Government
a cost advantage over Amazon of 1.5 *million* *times*.
Let's do one more gedankenexperiment. Get a good mouthful of coffee and your
new keyboard. Go over to a mirror and look into the mirror while holding your
keyboard under your chin. Now think to yourself ten times, "When it comes to
cloud computing, the government is a million times more clueful than Amazon."
Go on. Let me know if your keyboard survives. I don't think I could do it
without laughing somewhere around the seventh or eighth iteration.
Do you see why I'm harumphing? Come on, if you have big security needs, nothing
improves the situation better than adding a few more characters to your
passphrase.
So, does any of this translate into anything actionable for this
committee? Maybe not right now. As I've already said, I think
scrypt is currently too young to be considered for standardization.
But that doesn't make the problem go away.
No, it doesn't. But the problem can be made to go away by picking a better
passphrase.
Trust the power of exponentials. (I hope I didn't ruin another keyboard with
that pun.)
The PGP product calibrates the iteration count on the running machine
to hit ~1/10 second. I ran it on my laptop and got an iteration count
of 1835008 (coded count 172).
Come to think of it, this too might be a problem soon. The biggest
value that the count octet can encode is 65011712, so that would only
be 3.54 seconds on your laptop. I can guarantee you that there are
already lots of GnuPG users who, if they were presented with a menu
option to have the S2K algorithm require 5 seconds, would take it.
Today you might justifiedly write this off as tinfoil-hattery, but
after Moore's law plays out for a few iterations on the scenario
I've described above, it won't be. Maybe this will be your excuse to
replace that encoding with something sane :-).
This is part of why I said that if you're going to replace the current
iterator, using PBKDF2 is sufficient. Or even just replacing that damned scaled
number with a nice longword. However, Werner underlines my other point. The
cost of tweaking the software is not zero. You have to build, test, deploy, and
so on. There will be bugs, too. These bugs have a very high cost, because they
translate either into lost data or compromised data.
However, even if you max the thing out, that multiplies the attacker's cost by
35 from what it is today, which is essentially one character in length. It
helps, but it's a linear improvement in an exponential system.
And all of this is why I roll my eyes at scrypt. It's looking at the problem
the wrong way. You need to have a KDF that is small and fast so it can be used
anywhere and then scaled. The ultimate answer, though, is to pick a long
password. It doesn't even have to be *that* long. Somewhere between 15 and 20
characters (and no dictionary words) and no one will ever break it through
brute force computing.
Jon
-----BEGIN PGP SIGNATURE-----
Version: PGP Universal 2.10.0 (Build 554)
Charset: us-ascii
wj8DBQFLIUdhsTedWZOD3gYRAr+fAKCUTL2p8IRfJLs/I6Jp7pccU4QC0wCfYlWf
bF4SVvQl9VvarNap076Nx5s=
=jWSw
-----END PGP SIGNATURE-----