---------- From: Steven Furlong[SMTP:sfurlong@acmenet.net] Reply To: Steven Furlong Sent: Thursday, September 28, 2000 9:00 PM To: Multiple recipients of list Subject: Bad Coding Practices
"Trei, Peter" wrote:
<<NSA et al inducing a company to write bad crypto software>>
2. Individual treachery.
This type involves corrupting one or more engineers, whether via money, threats, or misplaced appeals to patriotism. This is more likely to succeed in the short term than type 1, but is very fragile for several reasons familiar to anyone who has done commercial software development.
* Peer code reviews mean that many eyes look at the code. * Employee turnover in the field is high - 30-50% year. Thus, bugs inserted by earlier compromised employees are unlikely to last through many release cycles, as new employees come in and say 'Oops - Joe forgot to init the PRNG properly - lets fix that!' * Source code management systems make it very difficult to a single actor to monkey with code secretly, and even harder to cover his tracks.
I'm less sanguine. What follows is mainly based on my experience as a consulting or contract programming, but it matches the comments of other programmers. I've never worked at a company which made privacy software, though several companies rolled their own crypto for their products.
- Code review? What's that? We can't waste time having programmers look over each others work. Besides, we don't want to make it look like we don't trust them.
Even in shops which did have code reviews, they usually consisted of Johnny-on-the-spot explaining in broad terms what a function did and going over a piece of which he was particularly proud while everyone else nodded sagely while thinking about their kid's soccer practice. I wouldn't want to testify that any of the "reviewers" had even read the code before or during the meeting.
My comments on code reviews is based on the practice at my current employer. When upper management supports the practice, and not only allows, but in fact requires engineers to take the time and effort to do real reviews, they can catch a remarkable number of errors. It also means that more than a single engineer is familiar with a given piece of code, which is a Good Thing.
- Depending on the shop, code which is difficult to understand may remain untouched for years. So long as it does what it's supposed to do, or its shortcomings can be compensated for at lower immediate cost than rewriting the blob, many places just leave it be. The code chunk might well be looked at by many eyes, but they'll all roll up before making much headway. So the moral for the subverted programmer is to write his poison pill very badly and don't explain how it works.
This is a real potential problem - old code that hasn't been looked at in years. Re-writing from spec every few years is one solution, but one that is rarely implemented.
- Many places I've worked have been too cheap to buy a version contol license for every developer, so everyone just logs in as PVCS and checks in changes. And hardly anyone looks at the comments, except to scan for comments like "Fixed bug #521".
Clearly, you've worked in places with shoddy (and possibly criminal) practices.
Now, I think your general point is right, that it would be somewhat difficult for a subverted programmer to insert deliberately broken crypto, and a very bet to expect it to stay in for any length of time. However, if the privacy software companies operate anything like the companies I've worked for or consulted at, it could well happen.
Eavesdroppers in and out of uniform will look for, and try to generate, poor practices which will break otherwise secure systems. What I find most worrying is when management only pays security lip-service, a bullet item for marketing, without any real desire to make it strong. Lucky's discovery that some GSM phones in the US have lousy or non-existant keying practices is one example. I've actually turned down jobs from firms where I felt that they wanted crypto as a bullet item rather than for real security (one place wanted to use 20 bit keys, for example. (they no longer exist)). Peter Trei
Disgustedly, SRF
-- Steve Furlong, Computer Condottiere Have GNU, will travel 518-374-4720 sfurlong@acmenet.net