[148633] in cryptography@c2.net mail archive
Re: [Cryptography] RSA is dead.
daemon@ATHENA.MIT.EDU (Dirk-Willem van Gulik)
Mon Dec 23 18:09:06 2013
X-Original-To: cryptography@metzdowd.com
From: Dirk-Willem van Gulik <dirkx@webweaving.org>
In-Reply-To: <alpine.LFD.2.02.1312230912440.4039@laptop.kerry-linux.ie>
Date: Mon, 23 Dec 2013 17:05:44 +0100
To: Ralf Senderek <crypto@senderek.ie>
Cc: Cryptography <cryptography@metzdowd.com>, ianG <iang@iang.org>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
Op 23 dec. 2013, om 09:40 heeft Ralf Senderek <crypto@senderek.ie> het volg=
ende geschreven:
> On Mon, 23 Dec 2013, ianG wrote:
> =
>> Open Source as a guarantee of security is really just the marketing of
>> the open source folk. It certainly helps but collecting those smart
>> eyeballs isn't as easy as saying it.
>> =
>> iang
> =
> Of course open source is never a guarantee, I didn't say that. We should
> not confuse a necessary condition with a sufficient one. But the RSA (Inc)
> marketing implied that closed-shop trusted expert crypto is superior to
> open source crypto products. And that is certainly false.
> =
> As Peter, Dirk-Willem and Jerry rightly pointed out, it is very difficult
> to find crafted backdoors even in open source products. But just because
> something is difficult, that doesn't mean it should not be done.
> =
> With open source it can be done. But some essential changes are needed.
> Those who have the ability to check crypto code must be actively engaged
> by the community / society. If there is no incentive nor any substantial
> acknowledgement of this important work, if code audit is mainly seen as p=
rivate activity with no financial rewards, then yes, we can forget
> security.
After thinking this over a bit - I am wondering though if the backdoor tell=
s the whole story. =
It may be good to consider this in the context of
http://www.acsac.org/2010/openconf/modules/request.php?module=3Doc_program=
&action=3Dview.php&a=3D&id=3D69&type=3D2 (*)
DOI 1920261.1920299
which shows that as software ages (open source or closed source) the "prope=
rties extrinsic to the software play a much greater role in the rate of vul=
nerability discovery than do intrinsic properties such as software quality=
=94. And that due to a difference in their early lives; open sources ends u=
p gradually faring better - and longer.
So if we assume that crypto code, by its nature, once implemented, is quite=
stable - and if we assume that the early period after the first release, o=
pen source sees (as this article argues) more stable/reliable fixes; and we=
add the assumption that groups of developers who are not in cahoots/from c=
ompeting interests/cultures/etc are likely/desirable - then one could concl=
ude that open source low level crypto libraries are about as =82good=92 as =
we, as an industry, know how to get.
Thanks,
Dw. =
* Abstract: Work on security vulnerabilities in software has primarily focu=
sed on three points in the software life-cycle: (1) finding and removing so=
ftware defects, (2) patching or hardening software after vulnerabilities ha=
ve been discovered, and (3) measuring the rate of vulnerability exploitatio=
n. This paper examines an earlier period in the software vulnerability life=
-cycle, starting from the release date of a version through to the disclosu=
re of the fourth vulnerability, with a particular focus on the time from re=
lease until the very first disclosed vulnerability.
Analysis of software vulnerability data, including up to a decade of data f=
or several versions of the most popular operating systems, server applicati=
ons and user applications (both open and closed source), shows that propert=
ies extrinsic to the software play a much greater role in the rate of vulne=
rability discovery than do intrinsic properties such as software quality. T=
his leads us to the observation that (at least in the first phase of a prod=
uct's existence), software vulnerabilities have different properties from s=
oftware defects.
We show that the length of the period after the release of a software produ=
ct (or version) and before the discovery of the first vulnerability (the 'H=
oneymoon' period) is primarily a function of familiarity with the system. I=
n addition, we demonstrate that legacy code resulting from code re-use is a=
major contributor to both the rate of vulnerability discovery and the numb=
ers of vulnerabilities found; this has significant implications for softwar=
e engineering principles and practice.
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
