CDR: Bad Coding Practices

[Steven Furlong]

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

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

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


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.

Disgustedly,
SRF

-- 
Steve Furlong, Computer Condottiere     Have GNU, will travel
   518-374-4720     sfurlong at acmenet.net