[148654] in cryptography@c2.net mail archive
Re: [Cryptography] how reliably do audits spot backdoors? (was: Re:
daemon@ATHENA.MIT.EDU (James A. Donald)
Tue Dec 24 13:04:16 2013
X-Original-To: cryptography@metzdowd.com
Date: Tue, 24 Dec 2013 17:32:53 +1000
From: "James A. Donald" <jamesd@echeque.com>
To: cryptography@metzdowd.com
In-Reply-To: <r422Ps-1075i-5787A29FEB1547A993116105232DF795@Williams-MacBook-Pro.local>
Reply-To: jamesd@echeque.com
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
On 2013-12-24 03:36, Bill Frantz wrote:
> Note that the bugs were limited to 100 lines of code because of the
> limited amount of time available for the code review. A real system
> would probably consist of many times 100 lines of code, especially if
> the compiler and runtime environments are included. Since backdoors can
> be designed that depend on "innocent" insertions in several separate
> parts of the code, the complexity of the search goes up faster than
> linearly with code size.
In code reviews, I automatically reject things that make the complexity
of the search go up faster than linearly.
The underhanded C examples all, or all I glanced at, used obfuscation,
uglification, and complexification, that would have been immediately
thrown out in code review, without anyone bothering to figure out what
the obfuscation obfuscated, what the uglified and complexified code
actually did.
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
