Re: Better S2K functions for OpenPGP?

Ian G <iang@systemics.com> Sun, 13 December 2009 14:13 UTC

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 <ietf-openpgp@imc.org>; 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 <iang@systemics.com>
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 <ietf-openpgp@imc.org>
CC: Daniel Franke <df@dfranke.us>
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: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

> 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