On Wed, 9 Dec 2009 14:20:46 -0800
Jon Callas <jon(_at_)callas(_dot_)org> wrote:
The OpenPGP one is more-or-less equivalent to PBKDF2. The major
difference is that you can use an HMAC or something like it in
PBKDF2, and the OpenPGP one just iterates a salted hash function. But
security-wise, there isn't any difference. You're looking at the
one-wayness of a hash function on very short inputs (I will define
very short to be 100 characters or less).
[...]
But on the other hand, if we wave a magic wand and put PBKDF2 (or
scrypt) into OpenPGP -- which by the way requires that you have
preferences for declaring which ones you support, I would recommend
to any and all developers that they not implement it. The reason is
it's more code, more debugging, more interop testing, and all for
something that has an added security that is less than epsilon for
many, many epsilon.
Ok, you have me in agreement that making changes to section 3.7.1
for the sole purpose of adding PBKDF2 support would be a bad idea.
But I have to disagree with you here:
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.
The situation is going to get worse with time. CPUs are currently
getting more parallel much faster than their clock rates are increasing.
KDFs, by design, can't be parallelized for a single passphrase. But
an attacker gets to parallelize all he wants. This means that over
time, the ratio between how long it takes the user to run the KDF on
his password and how long it takes an attacker to crack it is going to
decrease. Iterated hashes, PBKDF2, and bcrypt all share this problem.
scrypt solves it by making memory the limiting factor in chip space.
As for smartcards, etc., I of course agree with you that scrypt isn't
appropriate for these environments. But I disagree that this is much
of a problem. Unlike when dealing with public key algorithms, the
cost of switching S2K algorithms is very low. Just enter your password,
decrypt your payload, generate a new encryption key with your new
KDF, and re-encrypt. There are no new public keys to distribute
and no webs of trust to rebuild. And anyway, I can't think of any
situation in which I'd have a payload destined for a smartcard and not
know that from the beginning. If I had a need for a PGP smartcard, I
wouldn't be storing the same key on it that I use to sign email.
scrypt is perfectly fine for virtual machines, though. While I think
of 16MB as the ideal memory demand and some tiny VMs might not want to
spare that, you still get plenty of benefit over PBKDF2 if you only
require 1MB, and that ought to be reasonable for any VM.
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.
"Every bit is sacred. Every bit is great. When a bit is wasted, Phil
gets quite irate."
I'm sending you a bill for my keyboard replacement.
I'll be encoding the dollar amounts in accordance with section 4.2.2.
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 :-).
--
Daniel Franke df(_at_)dfranke(_dot_)us http://www.dfranke.us
|----| =|\ \\\\
|| * | -|-\--------- Man is free at the instant he wants to be.
-----| =| \ /// --Voltaire
signature.asc
Description: PGP signature