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 _______________________________________________ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. _______________________________________________
