CDR: RE: Bad Coding Practices

Trei, Peter ptrei at rsasecurity.com
Fri Sep 29 10:21:42 PDT 2000



> ----------
> From: 	Steven Furlong[SMTP:sfurlong at 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 at acmenet.net
> 
> 






More information about the cypherpunks-legacy mailing list