Domain: acsa-admin.org
Stories and comments across the archive that link to acsa-admin.org.
Comments · 7
-
Re:How about the build tools and the OS?
You just might want to look 'Diverse Double-Compiling' as a method of countering the attack described by Ken Thompson in 'Reflections on Trusting Trust'. A paper on DDC is at http://www.acsa-admin.org/2005...
-
Re:enigmail/pgp/gpg
What percentage of you have downloaded the source code, verified the MD5 of the source code against what is reported, then compiled it yourself using compilers that you trust aren't compromised?
The authors of those programs make it easy to verify by publishing the hash along with the source and encouraging people to verify their downloads. I expect your distribution's maintainer follows those protocols when building the released version. That build is automatically signed when built and verified upon download when installing it on your system.
As for trusting your compiler, I assume you're referring to Ken Thompson's seminal Reflections on Trusting Trust (PDF). It's an interesting academic exercise, but I'm pretty sure if such a compiler were out there and in common use, someone would have noticed. Especially now that there is a published way to detect it.
Installing the distro's version is likely safe, although you must realize you're opening up your circle of trust to include the distro's maintainer and server farm instead of just the original author(s) and their source repository.
The bad part of this is, until we get NSA's unconstitutional programs back under control, simply encrypting your emails may be enough to trigger their systems to preserve it. -
Re:Wait, what?
Whoa, not so fast... there may be a way around that, see http://www.acsa-admin.org/2005/abstracts/47.html
-
Trusting Trust has a counter...
If you are posting the seminal Trusting Trust, you should also post Countering Trusting Trust to balance it. It is possible to escape the trojaned compiler problem through the use of double diverse compilation.
-
Re:A DRM ban clause should be added as a constitut
There is of course also the not-yet-quite-as-well-known article about a method to defeat that attack. You might want to read it (I have) since it's actually rather nice.
One location is at http://www.acsa-admin.org/2005/abstracts/47.html
Or more info, as well as the paper, on the author's blog at http://www.dwheeler.com/trusting-trust/
So, if you distrust your compiler(s) enough, there are ways for you to regain that trust, either by yourself or by enlisting some help.
-
Re:How about a software solution?
And here is something for you to read.
-
Countering Trusting Trust through Diverse Double-C
You can test the compiler's trustworthiness.
http://www.acsa-admin.org/2005/abstracts/47.html
Countering Trusting Trust through Diverse Double-Compiling
David A. Wheeler
Institute for Defense Analyses
USA
An Air Force evaluation of Multics, and Ken Thompson's famous Turing award lecture "Reflections on Trusting Trust," showed that compilers can be subverted to insert malicious Trojan horses into critical software, including themselves. If this attack goes undetected, even complete analysis of a system's source code will not find the malicious code that is running, and methods for detecting this particular attack are not widely known. This paper describes a practical technique, termed diverse double-compiling (DDC), that detects this attack and some unintended compiler defects as well. Simply recompile the purported source code twice: once with a second (trusted) compiler, and again using the result of the first compilation. If the result is bit-for-bit identical with the untrusted binary, then the source code accurately represents the binary. This technique has been mentioned informally, but its issues and ramifications have not been identified or discussed in a peer-reviewed work, nor has a public demonstration been made. This paper describes the technique, justifies it, describes how to overcome practical challenges, and demonstrates it.