Ian G | 13 Dec 2009 15:13

Re: Better S2K functions for OpenPGP?


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

(Continue reading)

Robert J. Hansen | 13 Dec 2009 16:10
Favicon

Re: Better S2K functions for OpenPGP?


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


Gmane