ietf-openpgp
[Top] [All Lists]

Re: Better S2K functions for OpenPGP?

2009-12-09 17:35:00

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Dec 9, 2009, at 12:17 PM, Daniel Franke wrote:

* PGP Signed by an unknown key

The discussion currently going on gnupg-dev about increasing the
default iteration count for the S2K prompted me to wonder whether
OpenPGP couldn't benefit from some more modern key-derivation
algorithms.

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). 

PBKDF2[1] is the most standard, while bcrypt[2] is also
well-tested and popular, and scrypt[3], although new, seems to be
superior to both of them.  The advantage of scrypt is that it's hard in
terms of space complexity as well as time complexity, greatly reducing
the advantage given to an attacker who has the ability to build custom
cryptographic hardware.

My opinion is that bcrypt is a fine replacement for crypt, but either PBKDF2 or 
the OpenPGP generator are in my opinion at least as good. They all date from 
about the same period. I also argue that you're better off starting with a hash 
function than whacking Blowfish into a one-way function. Really, I trust the 
security SHA2 a lot more than I trust Eskblowfish.

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.

One can certainly complain about the OpenPGP S2K system. I'll be happy to. The 
iteration count as a one-byte floating point number is madness. It's hard to 
understand, impossible to read by humans, and has caused in-the-field software 
issues because someone implemented the thing wrong. It's an embodiment of my 
snarky characterization of many things in OpenPGP, "Every bit is sacred. Every 
bit is great. When a bit is wasted, Phil gets quite irate." It'a too clever by 
half.

Other than that -- what problem are you trying to solve?

Sure, if I were starting a new project right now, I'd use PBKDF2. You might 
even convince me to use scrypt if the system was never going to run in (or have 
to interoperate with) a constrained environment like a smartcard, a smartphone, 
a doorknob, or a virtual machine.

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.

To see how well the existing system does, go to:

http://news.electricalchemy.net/2009/10/cracking-passwords-in-cloud.html

http://news.electricalchemy.net/2009/10/password-cracking-in-cloud-part-5.html


and read them. 

The summary is that they set out to crack a PGP Zip file (which is nothing more 
than a .tar.pgp file) with Amazon EC2 and the CPU cost for brute-forcing a 
12-character, lowercase-only password is $1.5 million.

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).

So to sum up -- why are you even debating about increasing the iteration count? 
And what security goal do you want that you aren't getting that is so 
compelling that you'd force a software update on every OpenPGP implementation?

        Jon




-----BEGIN PGP SIGNATURE-----
Version: PGP Universal 2.10.0 (Build 554)
Charset: us-ascii

wj8DBQFLICCesTedWZOD3gYRAiDWAJ9mGyecxy11CDGnwG8IpIL0jvKgGACgnAWl
qd5yW4MWHuaxsIKfJQqwktw=
=oJWM
-----END PGP SIGNATURE-----