Subject: Re: Better S2K functions for OpenPGP?
From: "Robert J. Hansen" <[email-masked]>
To: Ian G <[email-masked]>
Cc: IETF OpenPGP Working Group <[email-masked]>, Daniel Franke <[email-masked]>
Date: Sun, 13 Dec 2009 10:10:42 -0500
List-Id: <ietf-openpgp.imc.org>

On 12/13/2009 09:13 AM, Ian G wrote:
> Security is a risk-based business, not an absolute science.

I agree with this entire message.  My comments here are just my own
postscript.

So far there's been talk about the marginal rewards from changing, but
not much talk about the risks.  If implementors abandon their mature,
stable s2k code in favor of a new s2k algorithm, the implementors will
very likely be increasing the bug count in their s2k code.  We hope
these bugs would get found quickly; however, there are no guarantees.
Those are two bottom-line truths we cannot get away from.

That doesn't mean components shouldn't be changed.  It just means
components shouldn't be changed lightly.  There needs to be an
engineering justification for changing the s2k algorithm, not just
"because it would be cool."

Date: Sun, 13 Dec 2009 15:13:40 +0100
From: Ian G <[email-masked]>
To: IETF OpenPGP Working Group <[email-masked]>
CC: Daniel Franke <[email-masked]>
Subject: Re: Better S2K functions for OpenPGP?
Sender: [email-masked]

> On Sun, 13 Dec 2009 04:09:37 +0100 Ian G wrote:
>> Has it ever been broken?  Has anyone lost anything?
>
> Define broken as used in this context.

Security is a risk-based business, not an absolute science.

In order to measure risks we generally have to either ground it in a 
business->threat->security model that indicates future dangers that will 
by experience cause us to cut them off before they happen;  OR, show 
that now there are losses / damages / breaches.

The former would be like, if 40 bit crypto was in place in SSL-protected 
retail sites, we'd expect real-time eavesdropping of credit cards from 
wireless hotspots by the year 20xx.  The latter would be like, in 20yy 
we saw N cases of people losing $zzzz because their password was 
crunched.  E.g., we have all these figures in various guises for 
phishing, data breaches, bank breaches.

So in absence of that, I'd say it ain't broken.  Don't fix it :)

Another way of saying it is, in the absence of a clear and present 
danger to our users, it is slightly brave to ask the protocol, standards 
and developer communities to do all the work required to make a new 
version happen.

> If you use a short enough
> password it's trivially breakable.

Doesn't that apply, regardless?

iang

Date: Sun, 13 Dec 2009 04:09:37 +0100
From: Ian G <[email-masked]>
CC: [email-masked]
Subject: Re: Better S2K functions for OpenPGP?
Sender: [email-masked]

On 09/12/2009 21:17, Daniel Franke wrote:
> 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.

Has it ever been broken?  Has anyone lost anything?

It's IMO not worth changing a standard unless there is a clear and 
present danger.

iang

From: Peter Gutmann <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Better S2K functions for OpenPGP?
Cc: [email-masked]
Date: Fri, 11 Dec 2009 11:05:24 +1300
Sender: [email-masked]

Jon Callas <[email-masked]> writes:

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

I was tempted to reply to an earlier message that said something like "the US 
intelligence budget is umpty-gazillion dollars and they're going to use all of 
it to build a hardware S2K machine to target me, personally" with "trust me, 
your collection of Paris Hilton vids just isn't that interesting to the NSA", 
but you've said it much better.

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

Precisely.

Peter.

Subject: Re: Better S2K functions for OpenPGP?
From: Jon Callas <[email-masked]>
Date: Thu, 10 Dec 2009 11:18:34 -0800
Cc: Jon Callas <[email-masked]>, [email-masked]
To: Daniel Franke <[email-masked]>
Sender: [email-masked]

>> 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.
>=20
> 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 bu=
ying a parallel computer with some real monetary metrics on it. You can sca=
le that metric however you want for whatever advantages or disadvantages yo=
u 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 passw=
ord down to $1. Note again, we're talking about lowercase-only passwords an=
d 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 o=
ne -- 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 trilli=
on dollars, which is the neighborhood of the entire recent economic meltdow=
n. If you want to argue, let's add one more character and end up with a cos=
t of $141 trillion bucks.

25 characters? $2,481,152,873,203,736,576. That's 2.5 * 10^18. Or 2.5 milli=
on trillion dollars. To reiterate once again, this is even granting The Gov=
ernment a cost advantage over Amazon of 1.5 *million* *times*.

Let's do one more gedankenexperiment. Get a good mouthful of coffee and you=
r 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 co=
mes 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 cou=
ld 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, not=
hing improves the situation better than adding a few more characters to you=
r 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 wit=
h that pun.)

>=20
>> 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).
>=20
> 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 iter=
ator, using PBKDF2 is sufficient. Or even just replacing that damned scaled=
 number with a nice longword. However, Werner underlines my other point. Th=
e cost of tweaking the software is not zero. You have to build, test, deplo=
y, and so on. There will be bugs, too. These bugs have a very high cost, be=
cause 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 proble=
m 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 l=
ong 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 t=
hrough brute force computing.=20

	Jon

Date: Thu, 10 Dec 2009 09:49:24 -0500
From: Daniel Franke <[email-masked]>
To: [email-masked]
Subject: Re: Better S2K functions for OpenPGP?
Sender: [email-masked]

--Sig_/_h2fDM+luLy64y0t9s6wkAo
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

On Thu, 10 Dec 2009 10:05:48 +0100
Werner Koch <[email-masked]> wrote:

> Anyway, the protected password is something which gives you a bit of
> time in case your key has been compromised.  But in a real world
> scenario it will never give you the protection of the public key
> encryption.  If someone can access your secret key - be it protected
> not not - you are lost.

If this is the desired security guarantee, then the salted/iterated
hash is already more than sufficient to fulfill it, it will continue to
be sufficient for decades or centuries to come, and there's no reason to
change.  But given the opportunity to make a stronger guarantee, I don't
understand why you'd be uninterested in taking it.  IMO it's reasonable
for a user to expect that cracking a good passphrase on his private key
should be just as hard as factoring his public key.

> Complexity is the worst enemy of a (security) software.  With each
> line of code we add more bugs.  After all we would add a maybe better
> algorithms in exchange for an increased probability of severe bugs.
> Those bugs are the problems and not any password cracking machines.

No argument from me here whatsoever; I agree that this is always a
tradeoff to consider for any new code.

--=20
 Daniel Franke         [email-masked]         http://www.dfranke.us
 |----| =3D|\     \\\\   =20
 || * | -|-\---------   Man is free at the instant he wants to be.=20
 -----| =3D|  \   ///     --Voltaire

--Sig_/_h2fDM+luLy64y0t9s6wkAo
Content-Type: application/pgp-signature; name=signature.asc
Content-Disposition: attachment; filename=signature.asc

--Sig_/_h2fDM+luLy64y0t9s6wkAo--

Date: Thu, 10 Dec 2009 10:05:48 +0100
From: Werner Koch <[email-masked]>
To: Daniel Franke <[email-masked]>
Cc: Peter Gutmann <[email-masked]>, [email-masked]
Subject: Re: Better S2K functions for OpenPGP?
OpenPGP: id=5B0358A2; url=finger:[email-masked]
Organization: g10 Code GmbH
Sender: [email-masked]

On Wed, 9 Dec 2009 17:40:12 -0500, Daniel Franke wrote:

> I don't think implementation difficulties are of primary concern.  Both

The concern is with the added code complexity.  We can't just add a
new KDF and drop the old one.  We already have too many algorithms we
need to implement so that a minimal OpenPGP implementation is not
quite complex already.

Complexity is the worst enemy of a (security) software.  With each
line of code we add more bugs.  After all we would add a maybe better
algorithms in exchange for an increased probability of severe bugs.
Those bugs are the problems and not any password cracking machines.

Anyway, the protected password is something which gives you a bit of
time in case your key has been compromised.  But in a real world
scenario it will never give you the protection of the public key
encryption.  If someone can access your secret key - be it protected
not not - you are lost.

For the case of symmetric only encryption no sane deployment would use
a 12 character passphrase but a random one stored in some key
management system.  If you get access to the key management system
your are again lost - no, you would not crack the passphrases but
sniff them.

Thus we better keep the current S2K in OpenPGP and adjust the
iteration count to match todays CPUs.

Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

Date: Thu, 10 Dec 2009 00:13:12 -0800
From: Colin Percival <[email-masked]>
To: [email-masked]
Subject: Re: Better S2K functions for OpenPGP?
Sender: [email-masked]

Jon Callas wrote:
> 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 estimated bcrypt as being a couple bits stronger against hardware attack than
PBKDF2, largely due to the large look-up tables blowfish uses, but I don't think
that's enough to justify using something non-standard.  Also, bcrypt only uses
55 bytes of passphrase, which could be a problem for passphrases with very low
entropy per character.

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

If you're concerned about attackers armed with custom hardware, chewing up RAM
is definitely a feature.  Note that it is quite simple to compute scrypt using
less RAM subject to [RAM size] * [CPU time] remaining constant.  (My published
library code doesn't do this, but if someone is interested I'd be happy to write
the necessary bits.)

If you don't think you're ever going to want to keep secrets from governments,
sure, PBKDF2 is fine.

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

Sure, but the security of a cryptosystem is determined by the *cheapest* attack
against it, not the *most expensive* attack against it.  Cloud computing is not
the cheapest way of attacking a KDF.

-- 
Colin Percival
Security Officer, FreeBSD | freebsd.org | The power to serve
Founder / author, Tarsnap | tarsnap.com | Online backups for the truly paranoid

Date: Thu, 10 Dec 2009 02:19:08 -0500
From: Daniel Franke <[email-masked]>
To: Jon Callas <[email-masked]>, [email-masked]
Subject: Re: Better S2K functions for OpenPGP?
Sender: [email-masked]

--Sig_/UvFv12vRbIBWb+5m99c+Nwe
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

On Wed, 9 Dec 2009 14:20:46 -0800
Jon Callas <[email-masked]> 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=20
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 :-).

--=20
 Daniel Franke         [email-masked]         http://www.dfranke.us
 |----| =3D|\     \\\\   =20
 || * | -|-\---------   Man is free at the instant he wants to be.=20
 -----| =3D|  \   ///     --Voltaire

--Sig_/UvFv12vRbIBWb+5m99c+Nwe
Content-Type: application/pgp-signature; name=signature.asc
Content-Disposition: attachment; filename=signature.asc

--Sig_/UvFv12vRbIBWb+5m99c+Nwe--

Subject: Re: Better S2K functions for OpenPGP?
From: David Shaw <[email-masked]>
Date: Wed, 9 Dec 2009 18:00:09 -0500
Cc: Daniel Franke <[email-masked]>, [email-masked]
To: Jon Callas <[email-masked]>
Sender: [email-masked]

On Dec 9, 2009, at 5:20 PM, Jon Callas wrote:

> 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).
>=20
> So to sum up -- why are you even debating about increasing the =
iteration count?

It wasn't much of a debate.  Summarized, the debate was: "Hey, this s2k =
count is kind of small for modern processors".  "Yes, let's make it =
bigger".  The current plan is to borrow the 1/10 second metric from PGP, =
as a default.  Users can override it if they need to, but I doubt there =
will be very much need to override.

I'm not in favor of adding a new s2k function, except *maybe* as a piece =
of a future v5 key format, which at least avoids some of the preferences =
and backwards compatibility issues.

David

Date: Wed, 9 Dec 2009 17:40:12 -0500
From: Daniel Franke <[email-masked]>
To: Peter Gutmann <[email-masked]>, [email-masked]
Subject: Re: Better S2K functions for OpenPGP?
Sender: [email-masked]

On Thu, 10 Dec 2009 09:50:31 +1300
Peter Gutmann <[email-masked]> wrote:

> I would support a move to PBKDF2 because it's widely supported,
> including the all-important PKCS #11 for hardware devices.  As for
> the other two, please, not another homebrew format that requires
> custom implementation support every time it's used...

I don't think implementation difficulties are of primary concern.  Both
bcrypt and scrypt have high-quality BSD-licensed C implementations,
which means they can easily be integrated into all the major PGP
implementations.  The more important question surrounding them is
whether they've been adequately vetted to be considered for
standardization.  My gut reaction for bcrypt is a hesitant yes, while
for scrypt it's an unhappy no (unhappy in the sense that I love
the idea behind scrypt and wish that the crypto community was
giving it more attention). But I think adding PBKDF2 is a no-brainer if
we make any changes at all to that section of the specification.

-- 
 Daniel Franke         [email-masked]         http://www.dfranke.us
 |----| =|\     \\\\    
 || * | -|-\---------   Man is free at the instant he wants to be. 
 -----| =|  \   ///     --Voltaire

Subject: Re: Better S2K functions for OpenPGP?
From: Jon Callas <[email-masked]>
Date: Wed, 9 Dec 2009 14:20:46 -0800
Cc: Jon Callas <[email-masked]>, [email-masked]
To: Daniel Franke <[email-masked]>
Sender: [email-masked]

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

> * PGP Signed by an unknown key
>=20
> 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 a=
ny 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).=20

> 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 PBKDF=
2 or the OpenPGP generator are in my opinion at least as good. They all dat=
e 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 ha=
rd to understand, impossible to read by humans, and has caused in-the-field=
 software issues because someone implemented the thing wrong. It's an embod=
iment of my snarky characterization of many things in OpenPGP, "Every bit i=
s 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 s=
martphone, a doorknob, or a virtual machine.

But on the other hand, if we wave a magic wand and put PBKDF2 (or scrypt) i=
nto OpenPGP -- which by the way requires that you have preferences for decl=
aring which ones you support, I would recommend to any and all developers t=
hat they not implement it. The reason is it's more code, more debugging, mo=
re interop testing, and all for something that has an added security that i=
s 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.h=
tml

and read them.=20

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-forci=
ng a 12-character, lowercase-only password is $1.5 million.

The PGP product calibrates the iteration count on the running machine to hi=
t ~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 co=
unt? 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 implementati=
on?

	Jon

From: Peter Gutmann <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Better S2K functions for OpenPGP?
Date: Thu, 10 Dec 2009 09:50:31 +1300
Sender: [email-masked]

Daniel Franke <[email-masked]> writes:

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

I would support a move to PBKDF2 because it's widely supported, including the 
all-important PKCS #11 for hardware devices.  As for the other two, please, 
not another homebrew format that requires custom implementation support every 
time it's used...

Peter.

Date: Wed, 9 Dec 2009 15:17:35 -0500
From: Daniel Franke <[email-masked]>
To: [email-masked]
Subject: Better S2K functions for OpenPGP?
Sender: [email-masked]

--Sig_/V7_Eci6P.IPvj.2JKdIn+c_
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

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

[1] http://www.rsa.com/rsalabs/node.asp?id=3D2127
[2] http://www.openbsd.org/papers/bcrypt-paper.ps
[3] http://www.tarsnap.com/scrypt.html

--=20
 Daniel Franke         [email-masked]         http://www.dfranke.us
 |----| =3D|\     \\\\   =20
 || * | -|-\---------   Man is free at the instant he wants to be.=20
 -----| =3D|  \   ///     --Voltaire

--Sig_/V7_Eci6P.IPvj.2JKdIn+c_
Content-Type: application/pgp-signature; name=signature.asc
Content-Disposition: attachment; filename=signature.asc

--Sig_/V7_Eci6P.IPvj.2JKdIn+c_--