[Cryptography] RSA is dead.

Dirk-Willem van Gulik dirkx at webweaving.org
Mon Dec 23 11:05:44 EST 2013


Op 23 dec. 2013, om 09:40 heeft Ralf Senderek <crypto at senderek.ie> het volgende 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 private activity with no financial rewards, then yes, we can forget
> security.

After thinking this over a bit - I am wondering though if the backdoor tells the whole story. 

It may be good to consider this in the context of

	http://www.acsac.org/2010/openconf/modules/request.php?module=oc_program&action=view.php&a=&id=69&type=2  (*)
	DOI 1920261.1920299

which shows that as software ages (open source or closed source) the "properties extrinsic to the software play a much greater role in the rate of vulnerability discovery than do intrinsic properties such as software quality”. And that due to a difference in their early lives; open sources ends up 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, open 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 competing interests/cultures/etc are likely/desirable - then one could conclude that open source low level crypto libraries are about as ‚good’ as we, as an industry, know how to get.

Thanks,

Dw. 

* Abstract: Work on security vulnerabilities in software has primarily focused on three points in the software life-cycle: (1) finding and removing software defects, (2) patching or hardening software after vulnerabilities have been discovered, and (3) measuring the rate of vulnerability exploitation. This paper examines an earlier period in the software vulnerability life-cycle, starting from the release date of a version through to the disclosure of the fourth vulnerability, with a particular focus on the time from release until the very first disclosed vulnerability.

Analysis of software vulnerability data, including up to a decade of data for several versions of the most popular operating systems, server applications and user applications (both open and closed source), shows that properties extrinsic to the software play a much greater role in the rate of vulnerability discovery than do intrinsic properties such as software quality. This leads us to the observation that (at least in the first phase of a product's existence), software vulnerabilities have different properties from software defects.

We show that the length of the period after the release of a software product (or version) and before the discovery of the first vulnerability (the 'Honeymoon' period) is primarily a function of familiarity with the system. In addition, we demonstrate that legacy code resulting from code re-use is a major contributor to both the rate of vulnerability discovery and the numbers of vulnerabilities found; this has significant implications for software engineering principles and practice.



More information about the cryptography mailing list