Fully Countering Trusting Trust through Diverse Double-Compiling

[ge at linuxbox.org (Gadi Evron)]

Wheeler, David A wrote:
> 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 :-).

Exactly, it is an endless process of trust, as you trust the second 
system/environment to be secure, or at least without a backdoor.

But while I really like the discussion, I don't want to take away from 
the value of your work. Thanks again for sharing!

        Gadi.


-- 
Gadi Evron,
ge at linuxbox.org.

Blog: http://gevron.livejournal.com/