Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nBDFBUka031486 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 13 Dec 2009 08:11:30 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id nBDFBUsk031485; Sun, 13 Dec 2009 08:11:30 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from shards.monkeyblade.net (shards.monkeyblade.net [198.137.202.13]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nBDFBSWv031479 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 13 Dec 2009 08:11:29 -0700 (MST) (envelope-from rjh@sixdemonbag.org) Received: from [10.1.10.2] (c-68-50-111-93.hsd1.dc.comcast.net [68.50.111.93] (may be forged)) (authenticated bits=0) by shards.monkeyblade.net (8.14.1/8.14.1) with ESMTP id nBDFAQaN011379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 13 Dec 2009 07:10:27 -0800 Message-ID: <4B2503F2.20704@sixdemonbag.org> Date: Sun, 13 Dec 2009 10:10:42 -0500 From: "Robert J. Hansen" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: Ian G CC: IETF OpenPGP Working Group , Daniel Franke Subject: Re: Better S2K functions for OpenPGP? References: <20091209151735.2444a67b@feanor.vpn.dfranke.us> <4B245AF1.5000408@systemics.com> <20091213003013.00003950@fingolfin.vpn.dfranke.us> <4B24F694.8040809@systemics.com> In-Reply-To: <4B24F694.8040809@systemics.com> X-Enigmail-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88.7/10158/Sat Dec 12 19:08:55 2009 on shards.monkeyblade.net X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.1.1 (shards.monkeyblade.net [198.137.202.13]); Sun, 13 Dec 2009 07:10:28 -0800 (PST) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 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." Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nBDEDi5Y028582 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 13 Dec 2009 07:13:44 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id nBDEDik7028581; Sun, 13 Dec 2009 07:13:44 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from fiddle.it (slice.reviewedpress.com [67.207.137.25] (may be forged)) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nBDEDhSa028575 for ; Sun, 13 Dec 2009 07:13:43 -0700 (MST) (envelope-from iang@systemics.com) Received: from [IPv6:::1] (localhost [127.0.0.1]) by fiddle.it (Postfix) with ESMTP id A70CC406C2; Sun, 13 Dec 2009 14:13:41 +0000 (UTC) Message-ID: <4B24F694.8040809@systemics.com> Date: Sun, 13 Dec 2009 15:13:40 +0100 From: Ian G User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: IETF OpenPGP Working Group CC: Daniel Franke Subject: Re: Better S2K functions for OpenPGP? References: <20091209151735.2444a67b@feanor.vpn.dfranke.us> <4B245AF1.5000408@systemics.com> <20091213003013.00003950@fingolfin.vpn.dfranke.us> In-Reply-To: <20091213003013.00003950@fingolfin.vpn.dfranke.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > 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 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nBD39e3H082077 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 12 Dec 2009 20:09:40 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id nBD39eOx082076; Sat, 12 Dec 2009 20:09:40 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from fiddle.it (slice.reviewedpress.com [67.207.137.25] (may be forged)) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nBD39d6D082063 for ; Sat, 12 Dec 2009 20:09:39 -0700 (MST) (envelope-from iang@systemics.com) Received: from [IPv6:::1] (localhost [127.0.0.1]) by fiddle.it (Postfix) with ESMTP id 21F44406C2; Sun, 13 Dec 2009 03:09:37 +0000 (UTC) Message-ID: <4B245AF1.5000408@systemics.com> Date: Sun, 13 Dec 2009 04:09:37 +0100 From: Ian G User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 CC: ietf-openpgp@imc.org Subject: Re: Better S2K functions for OpenPGP? References: <20091209151735.2444a67b@feanor.vpn.dfranke.us> In-Reply-To: <20091209151735.2444a67b@feanor.vpn.dfranke.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 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 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nBAM5TBt064538 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Dec 2009 15:05:29 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id nBAM5TEp064537; Thu, 10 Dec 2009 15:05:29 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailhost.auckland.ac.nz (larry.its.auckland.ac.nz [130.216.12.34]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nBAM5QCt064530 for ; Thu, 10 Dec 2009 15:05:27 -0700 (MST) (envelope-from pgut001@wintermute01.cs.auckland.ac.nz) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id A0DBE1B270; Fri, 11 Dec 2009 11:05:25 +1300 (NZDT) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e8IG-xuykoMU; Fri, 11 Dec 2009 11:05:25 +1300 (NZDT) Received: from mf1.fos.auckland.ac.nz (mf1.fos.auckland.ac.nz [130.216.33.150]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mailhost.auckland.ac.nz (Postfix) with ESMTP id A9D821A03D; Fri, 11 Dec 2009 11:05:24 +1300 (NZDT) Received: from wintermute01.cs.auckland.ac.nz ([130.216.34.38]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1NIr8W-0006oT-HX; Fri, 11 Dec 2009 11:05:24 +1300 Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1NIr8W-0002ux-By; Fri, 11 Dec 2009 11:05:24 +1300 From: Peter Gutmann To: df@dfranke.us, jon@callas.org Subject: Re: Better S2K functions for OpenPGP? Cc: ietf-openpgp@imc.org In-Reply-To: <56CD26AA-5808-49C1-8B87-2D90F610B329@callas.org> Message-Id: Date: Fri, 11 Dec 2009 11:05:24 +1300 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jon Callas 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. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nBAJIkLI050219 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Dec 2009 12:18:46 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id nBAJIjcV050217; Thu, 10 Dec 2009 12:18:45 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (merrymeet.com [66.93.68.160]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nBAJIiSI050206 for ; Thu, 10 Dec 2009 12:18:44 -0700 (MST) (envelope-from jon@callas.org) Received: from localhost (localhost [127.0.0.1]) by merrymeet.com (Postfix) with ESMTP id EF61E2E692 for ; Thu, 10 Dec 2009 11:19:47 -0800 (PST) Received: from merrymeet.com ([127.0.0.1]) by localhost (host.domain.tld [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 89644-09 for ; Thu, 10 Dec 2009 11:19:44 -0800 (PST) Received: from keys.merrymeet.com (keys.merrymeet.com [66.93.68.161]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTPA id 578AD2E66F for ; Thu, 10 Dec 2009 11:19:40 -0800 (PST) Received: from [10.0.23.101] ([66.93.68.163]) by keys.merrymeet.com (PGP Universal service); Thu, 10 Dec 2009 11:09:21 -0800 X-PGP-Universal: processed; by keys.merrymeet.com on Thu, 10 Dec 2009 11:09:21 -0800 Subject: Re: Better S2K functions for OpenPGP? Mime-Version: 1.0 (Apple Message framework v1077) From: Jon Callas In-Reply-To: <20091210021908.00002ec7@fingolfin.vpn.dfranke.us> Date: Thu, 10 Dec 2009 11:18:34 -0800 Cc: Jon Callas , ietf-openpgp@imc.org Message-Id: <56CD26AA-5808-49C1-8B87-2D90F610B329@callas.org> References: <20091209151735.2444a67b@feanor.vpn.dfranke.us> <20091210021908.00002ec7@fingolfin.vpn.dfranke.us> To: Daniel Franke X-Mailer: Apple Mail (2.1077) X-PGP-Encoding-Format: Partitioned X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: quoted-printable X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=us-ascii Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: QUOTED-PRINTABLE X-Virus-Scanned: Maia Mailguard Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----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. >=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 -----BEGIN PGP SIGNATURE----- Version: PGP Universal 2.10.0 (Build 554) Charset: us-ascii wj8DBQFLIUdhsTedWZOD3gYRAr+fAKCUTL2p8IRfJLs/I6Jp7pccU4QC0wCfYlWf bF4SVvQl9VvarNap076Nx5s=3D =3DjWSw -----END PGP SIGNATURE----- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nBAEnRnZ022741 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Dec 2009 07:49:28 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id nBAEnRQk022740; Thu, 10 Dec 2009 07:49:27 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from felagund.dfranke.us (felagund.dfranke.us [74.207.241.162]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nBAEnPJ9022734 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 10 Dec 2009 07:49:26 -0700 (MST) (envelope-from df@dfranke.us) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=dfranke.us; h=date:from :to:subject:message-id:in-reply-to:references:mime-version: content-type; s=default; bh=aYBIY3wVHt6cKdeib5tfML0QFSLPPg5WSM/g xCA48n8=; b=GaU14W4vpPYALYrPpObmZWv/GAm0+PgPuqJjSd/H0UaV16mVK7X2 AVdeKE8fGdQ+ljCi8ytBZE8BuKO+kQPHgrkLUb0RreJ6LwbfMDi8JOG1apGYluqo TRUwxOzqio89+gGY3OO6BcMmwG3B+I7ABDc8N6VvHM6I9N6LOh8l0G6OdSRFA1FQ AMEVeIEfM6yKXJ4wMwrVgQOFzQ7urfpAZk4GP1A/zPm3t/Z5CMHSY1GlHKddRBHL xPgXXrmbDWWAEl3pQIQwdWZGF1eiKlugGdCQOuGAiotFbb+2e1oBk6h8mOp23ksx 5tQx19GzAod8Orcvb5/kJCkNiP59foT8ug== Received: (qmail 13086 invoked from network); 10 Dec 2009 14:48:53 -0000 Received: from unknown (HELO fingolfin.vpn.dfranke.us) (172.20.17.4) by felagund.dfranke.us with SMTP; 10 Dec 2009 14:48:53 -0000 Date: Thu, 10 Dec 2009 09:49:24 -0500 From: Daniel Franke To: ietf-openpgp@imc.org Subject: Re: Better S2K functions for OpenPGP? Message-ID: <20091210094924.00006799@fingolfin.vpn.dfranke.us> In-Reply-To: <87ocm7qjv7.fsf@vigenere.g10code.de> References: <20091209151735.2444a67b@feanor.vpn.dfranke.us> <20091209174012.0000452d@fingolfin.vpn.dfranke.us> <87ocm7qjv7.fsf@vigenere.g10code.de> X-Mailer: Claws Mail 3.7.2cvs27 (GTK+ 2.16.0; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA256; boundary="Sig_/_h2fDM+luLy64y0t9s6wkAo"; protocol="application/pgp-signature" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --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 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 df@dfranke.us 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) iF4EAREIAAYFAkshCngACgkQ8tqcOcPA7qPTEAD8Csa1Ko5/p5ZeQk7+jCT7L1h3 Ok3nu9EV14PQkIdOjsoBAIUDukeIKv4Fzq1GSTGCcLuBVl2jQWLJ5zugc6PGPmnF =ZAjv -----END PGP SIGNATURE----- --Sig_/_h2fDM+luLy64y0t9s6wkAo-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nBA9AESP085458 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Dec 2009 02:10:14 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id nBA9AETp085455; Thu, 10 Dec 2009 02:10:14 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nBA9ABMB085438 for ; Thu, 10 Dec 2009 02:10:12 -0700 (MST) (envelope-from wk@gnupg.org) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.63 #1 (Debian)) id 1NIf2H-0007Ik-Rh for ; Thu, 10 Dec 2009 10:10:09 +0100 Received: from localhost ([127.0.0.1] helo=vigenere.g10code.de ident=wk) by vigenere.g10code.de with esmtp (Exim 4.69 #1 (Debian)) id 1NIey5-0002Wv-8d; Thu, 10 Dec 2009 10:05:49 +0100 Date: Thu, 10 Dec 2009 10:05:48 +0100 Message-ID: <87ocm7qjv7.fsf@vigenere.g10code.de> From: Werner Koch To: Daniel Franke Cc: Peter Gutmann , ietf-openpgp@imc.org Subject: Re: Better S2K functions for OpenPGP? In-Reply-To: <20091209174012.0000452d@fingolfin.vpn.dfranke.us> References: <20091209151735.2444a67b@feanor.vpn.dfranke.us> <20091209174012.0000452d@fingolfin.vpn.dfranke.us> User-Agent: Wanderlust/2.15.6 OpenPGP: id=5B0358A2; url=finger:wk@g10code.com Organization: g10 Code GmbH MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 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. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nBA8DL14079598 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Dec 2009 01:13:22 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id nBA8DLWd079597; Thu, 10 Dec 2009 01:13:21 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nBA8DKE0079591 for ; Thu, 10 Dec 2009 01:13:20 -0700 (MST) (envelope-from cperciva@alumni.sfu.ca) Received: from xps.daemonology.net (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx2.freebsd.org (Postfix) with SMTP id 2A0B014E683 for ; Thu, 10 Dec 2009 08:13:13 +0000 (UTC) Received: (qmail 62030 invoked from network); 10 Dec 2009 08:13:12 -0000 Received: from unknown (HELO xps.daemonology.net) (127.0.0.1) by localhost with SMTP; 10 Dec 2009 08:13:12 -0000 Message-ID: <4B20AD98.80009@alumni.sfu.ca> Date: Thu, 10 Dec 2009 00:13:12 -0800 From: Colin Percival User-Agent: Thunderbird 2.0.0.23 (X11/20090919) MIME-Version: 1.0 To: ietf-openpgp@imc.org Subject: Re: Better S2K functions for OpenPGP? X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 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 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nBA7JHN3074058 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Dec 2009 00:19:18 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id nBA7JHTW074057; Thu, 10 Dec 2009 00:19:17 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from felagund.dfranke.us (felagund.dfranke.us [74.207.241.162]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nBA7JEEq074051 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 10 Dec 2009 00:19:15 -0700 (MST) (envelope-from df@dfranke.us) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=dfranke.us; h=date:from :to:subject:message-id:in-reply-to:references:mime-version: content-type; s=default; bh=u3pFgU11dZX/QxKYJV5qHbynk59tgRTXACUt U8CaejY=; b=nX7Y0AGNqEtlU5Vo+cfAXTh0OLTAZ3e7ndKs/GbvNRNBJbdPWDly iV4zXHZ7a8FvVBw7wv3q/W6hl1qg8upACwY/6iilSlvwMZcKUe5HIvAZNc5HGGAe qw3Q3qfAJhPr+eDcD7MCuByKbpvYcPOFp13sQPWMLZtJE166ZlcVPzEKto46WrUG 4QkuaDIAo8SYj2DE/kCAnBXnqCA2QEWOKG3CJ8X9X5ud6KiU9MPMwFxLtV5KTPXO /UUV7DRltQBUSC7xY35uMCQcbr1Sz+FsJMjKO8bw/wQbbH+7QHYwqHcCGP6ua5xu 2hfLiNrw7qxr5kw2wal+H99rXIUdsCZEsQ== Received: (qmail 11298 invoked from network); 10 Dec 2009 07:18:42 -0000 Received: from unknown (HELO fingolfin.vpn.dfranke.us) (172.20.17.4) by felagund.dfranke.us with SMTP; 10 Dec 2009 07:18:42 -0000 Date: Thu, 10 Dec 2009 02:19:08 -0500 From: Daniel Franke To: Jon Callas , ietf-openpgp@imc.org Subject: Re: Better S2K functions for OpenPGP? Message-ID: <20091210021908.00002ec7@fingolfin.vpn.dfranke.us> In-Reply-To: References: <20091209151735.2444a67b@feanor.vpn.dfranke.us> X-Mailer: Claws Mail 3.7.2cvs27 (GTK+ 2.16.0; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA256; boundary="Sig_/UvFv12vRbIBWb+5m99c+Nwe"; protocol="application/pgp-signature" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --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 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 df@dfranke.us 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) iF4EAREIAAYFAksgoPQACgkQ8tqcOcPA7qNgkwD9ESw7oRERwo50WewoABG3R7zQ DCsnm8Cu4e37ei/pGRgA/jNBOc+VpuTnzCd8S0BQyDz+lqcOF5j5HQ/IBYkBWv+T =dWmz -----END PGP SIGNATURE----- --Sig_/UvFv12vRbIBWb+5m99c+Nwe-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nB9N0H7C029280 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Dec 2009 16:00:17 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id nB9N0Ge7029277; Wed, 9 Dec 2009 16:00:16 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from walrus.jabberwocky.com (walrus.jabberwocky.com [173.9.29.57]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nB9N0DQx029268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 9 Dec 2009 16:00:15 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from dshaw.nasuni.net (wasabi.nasuni.net [65.202.22.178]) (authenticated bits=0) by walrus.jabberwocky.com (8.14.3/8.14.3) with ESMTP id nB9N0AGe013540 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 9 Dec 2009 18:00:10 -0500 Subject: Re: Better S2K functions for OpenPGP? Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: David Shaw In-Reply-To: Date: Wed, 9 Dec 2009 18:00:09 -0500 Cc: Daniel Franke , ietf-openpgp@imc.org Content-Transfer-Encoding: quoted-printable Message-Id: <55B1F81D-AA10-4A95-8B74-F143D8002C71@jabberwocky.com> References: <20091209151735.2444a67b@feanor.vpn.dfranke.us> To: Jon Callas X-Mailer: Apple Mail (2.1077) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 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 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nB9MeDRg027999 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Dec 2009 15:40:13 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id nB9MeCNm027998; Wed, 9 Dec 2009 15:40:12 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from felagund.dfranke.us (felagund.dfranke.us [74.207.241.162]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nB9MeBGH027990 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 9 Dec 2009 15:40:11 -0700 (MST) (envelope-from df@dfranke.us) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=dfranke.us; h=date:from :to:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=default; bh=FJ6usTIo8 D0j31LCKi8SXEZIXWx4+5l6dje7UEh8y0k=; b=lUOtZyJt1GZVDZsipcihydF6o B1IVCaYMWmMlsuTSFQ8xsnH28s32Xc7J8WWjfQOr1G5BGugQ4u/7BX3/952o6rkp lKycIbav6NDOeduNKjlawHKxXXqJitjz0SZWehaOAtcev5ysaQw3uegFHiiDquf0 e+OoTra2ZpMgARPv9fZd8kmb8gUuDbTg1HtNHL9CsiWUdYkEDeMLb41LIHa9p94K ZxZIUw2FjYELqrcg2ITW4ZMwYTbIRtd92WNVcilXMBgQTc7U1/peGch8bCyk9X/C N7/xG2ydRAelmKVLSboJ6wF7uINCxQGnZPoXJm5HVfZ8WqN6lcZNuPLzdOxfQ== Received: (qmail 9296 invoked from network); 9 Dec 2009 22:39:39 -0000 Received: from unknown (HELO fingolfin.vpn.dfranke.us) (172.20.17.4) by felagund.dfranke.us with SMTP; 9 Dec 2009 22:39:39 -0000 Date: Wed, 9 Dec 2009 17:40:12 -0500 From: Daniel Franke To: Peter Gutmann , ietf-openpgp@imc.org Subject: Re: Better S2K functions for OpenPGP? Message-ID: <20091209174012.0000452d@fingolfin.vpn.dfranke.us> In-Reply-To: References: <20091209151735.2444a67b@feanor.vpn.dfranke.us> X-Mailer: Claws Mail 3.7.2cvs27 (GTK+ 2.16.0; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 10 Dec 2009 09:50:31 +1300 Peter Gutmann 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 df@dfranke.us http://www.dfranke.us |----| =|\ \\\\ || * | -|-\--------- Man is free at the instant he wants to be. -----| =| \ /// --Voltaire Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nB9MKwwb026648 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Dec 2009 15:20:58 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id nB9MKwIG026647; Wed, 9 Dec 2009 15:20:58 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (merrymeet.com [66.93.68.160]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nB9MKubE026641 for ; Wed, 9 Dec 2009 15:20:57 -0700 (MST) (envelope-from jon@callas.org) Received: from localhost (localhost [127.0.0.1]) by merrymeet.com (Postfix) with ESMTP id 599E62E63B for ; Wed, 9 Dec 2009 14:21:58 -0800 (PST) Received: from merrymeet.com ([127.0.0.1]) by localhost (host.domain.tld [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 75984-06 for ; Wed, 9 Dec 2009 14:21:55 -0800 (PST) Received: from keys.merrymeet.com (keys.merrymeet.com [66.93.68.161]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTPA id 40C1A2E1FF for ; Wed, 9 Dec 2009 14:21:51 -0800 (PST) Received: from il0102f-dhcp111.apple.com ([17.201.126.111]) by keys.merrymeet.com (PGP Universal service); Wed, 09 Dec 2009 14:11:42 -0800 X-PGP-Universal: processed; by keys.merrymeet.com on Wed, 09 Dec 2009 14:11:42 -0800 Subject: Re: Better S2K functions for OpenPGP? Mime-Version: 1.0 (Apple Message framework v1077) From: Jon Callas In-Reply-To: <20091209151735.2444a67b@feanor.vpn.dfranke.us> Date: Wed, 9 Dec 2009 14:20:46 -0800 Cc: Jon Callas , ietf-openpgp@imc.org Message-Id: References: <20091209151735.2444a67b@feanor.vpn.dfranke.us> To: Daniel Franke X-Mailer: Apple Mail (2.1077) X-PGP-Encoding-Format: Partitioned X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: quoted-printable X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=us-ascii Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: QUOTED-PRINTABLE X-Virus-Scanned: Maia Mailguard Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 -----BEGIN PGP SIGNATURE----- Version: PGP Universal 2.10.0 (Build 554) Charset: us-ascii wj8DBQFLICCesTedWZOD3gYRAiDWAJ9mGyecxy11CDGnwG8IpIL0jvKgGACgnAWl qd5yW4MWHuaxsIKfJQqwktw=3D =3DoJWM -----END PGP SIGNATURE----- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nB9KocwO018049 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Dec 2009 13:50:39 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id nB9KocsO018047; Wed, 9 Dec 2009 13:50:38 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailhost.auckland.ac.nz (moe.its.auckland.ac.nz [130.216.12.37]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nB9Koanl018040 for ; Wed, 9 Dec 2009 13:50:37 -0700 (MST) (envelope-from pgut001@wintermute01.cs.auckland.ac.nz) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id EE03C170E1E; Thu, 10 Dec 2009 09:50:34 +1300 (NZDT) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SPY31NDEeFIh; Thu, 10 Dec 2009 09:50:34 +1300 (NZDT) Received: from mf1.fos.auckland.ac.nz (mf1.fos.auckland.ac.nz [130.216.33.150]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 34896483909; Thu, 10 Dec 2009 09:50:31 +1300 (NZDT) Received: from wintermute01.cs.auckland.ac.nz ([130.216.34.38]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1NITUV-0003ew-JE; Thu, 10 Dec 2009 09:50:31 +1300 Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1NITUV-0003Ci-S2; Thu, 10 Dec 2009 09:50:31 +1300 From: Peter Gutmann To: df@dfranke.us, ietf-openpgp@imc.org Subject: Re: Better S2K functions for OpenPGP? In-Reply-To: <20091209151735.2444a67b@feanor.vpn.dfranke.us> Message-Id: Date: Thu, 10 Dec 2009 09:50:31 +1300 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Daniel Franke 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. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nB9KJ5t0015636 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Dec 2009 13:19:06 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id nB9KJ5Kr015635; Wed, 9 Dec 2009 13:19:05 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from felagund.dfranke.us (felagund.dfranke.us [74.207.241.162]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nB9KJ3un015626 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 9 Dec 2009 13:19:04 -0700 (MST) (envelope-from df@dfranke.us) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=dfranke.us; h=date:from :to:subject:message-id:mime-version:content-type; s=default; bh= ikwVsMBCeoHdfnpvSHOpisYz8aIDE5+2jyzwSeIZeok=; b=p/zBJJO4WhrYmGeV +TSIaxPCQHK9EAufnmzMP6+LzhyU/TlnfVeWM2qo9481HkOKx1CKT3ee+6x+kof+ z+GdkqKsr5ycps4WP72t7UVcJPLz+D0b9Kq3YlOR3YlyAvFXSay+2JanSimAp543 LUnPcZNMYEtfsV9uajXPpxfXNnNTD0zOQ8VbvUPintfgAqkNwrsXWyOiF0kBEL9p sk78QoUcFhhhR2J2ar5mFLzoTVBNpTyAfFzqi3ee/s/582DuDtyCc67leagEchtm 81CxVf383g8wk1U4cOKKnotqhYc3ilsrUgALzWXBjHc0yFKbMmXn4ncFcMcP1zLD G/jiyA== Received: (qmail 8574 invoked from network); 9 Dec 2009 20:18:31 -0000 Received: from unknown (HELO feanor.vpn.dfranke.us) (172.20.17.2) by felagund.dfranke.us with SMTP; 9 Dec 2009 20:18:31 -0000 Date: Wed, 9 Dec 2009 15:17:35 -0500 From: Daniel Franke To: ietf-openpgp@imc.org Subject: Better S2K functions for OpenPGP? Message-ID: <20091209151735.2444a67b@feanor.vpn.dfranke.us> X-Mailer: Claws Mail 3.7.2 (GTK+ 2.18.3; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA512; boundary="Sig_/V7_Eci6P.IPvj.2JKdIn+c_"; protocol="application/pgp-signature" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --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 df@dfranke.us 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iF4EAREKAAYFAksgBd8ACgkQ8tqcOcPA7qPd8QEAgz5GLeycH9fEKPL/MUNSqaxG O7GYHU6/pZKElB/x1FUA/iaDGNzh+yG+c69APogJE2Es/210mj2Vr61MihgLGO5N =XtLT -----END PGP SIGNATURE----- --Sig_/V7_Eci6P.IPvj.2JKdIn+c_--