Fully Countering Trusting Trust through Diverse Double-Compiling

[dwheeler at ida.org (Wheeler, David A)]

Gadi Evron said:
> David, this is very cool indeed. Thank you for sharing, and a lot of luck!

Thanks!

> I'd like to note in a semi-related fashion that the concept of trusting
> trust, while in the original paper limited to the compiler case, is a
> generic concept in security and could go on up and down the chain of
> trust forever (beyond the compiler), until at some point you take
> something on blind faith.

Actually, I talk about that in the dissertation.

First, it is perfectly reasonable to redefine the word "compiler" to include all sorts of components that you might 
traditionally define as part of the "environment".  For example, you could include the entire operating system as well 
as what we would traditionally define as "compiler".  Of course, now you need all of ITS source code, as a different 
trusted compiler that's able to compile it, as well as time to make it work.  The good news is that, once you did that, 
you'd have then verified that ALL of those executables correspond to their source code.

Second, I do not agree that this is BLIND faith.  I agree that you must eventually accept SOME set of components as 
being sufficiently trustworthy.  But the idea is to use a separate trusted compiler/environment to verify your original 
items.  At that point, I don't think it's BLIND at all; you hope the original components are okay, but you've also 
performed a verification step to increase your confidence that this is so.  The phrase "trust, but verify" comes to 
mind :-).

--- David A. Wheeler