3 ms·

"Trusting Trust" and the halting problem are often misinterpreted in similar ways. Unbounded skepticism is not right take-away from either of those results. I

"Trusting Trust" and the halting problem are often misinterpreted in similar ways. Unbounded skepticism is not right take-away from either of those results. I don't have a solution to the halting problem, but I can definitely tell you that `while(false) {}` terminates. Similarly, I can't resolve the problem of trusting the people who write the libraries I use, but I identify a trusted computing base and substantially reduce or even sometimes eliminate the risk of attacks that don't violate the integrity of the TCB. > This paper convinced me that pragmatically all computer security reduces to theater. I have yet to be bitten by a smashed stack using any language other than C/C++. I have yet to be bitten by a SQL injection using any interface to a DB other than passing raw strings around. As Ken notes, I still have to trust the developers of those libraries/languages (or audit the code myself). But that's okay. Nailing down a chain of trust is possible. Ruling out certain classes of security vulnerabilities is possible. > One of my ex-NSA buddies told me that they don't even bother attacking crypto algorithms, they just attack the implementation. Again, a solvable problem^1. Within the next 5-10 years, they might have to go back to attacking the algorithms. [^1]: See e.g., https://www.wireguard.com/papers/zinzindohoue-bhargavan-protzenko-beurdouche-hacl-2017.pdf https://www.wireguard.com/papers/zinzindohoue-bhargavan-prot... Note that the first sentence of Ken's paper still holds, but the number of people you have to trust can be reduced if you only need to trust the verifier's kernel instead of every line of code committed from every contributor.

User23 6y ago
It's possible to provably construct a program that will halt. That is the whole point of loop invariants. Similarly it is possible to provably construct a "secure" program up to physical limitations. However in both cases it requires that the semantics of the programming environment are known to the programmer. Even without a malicious adversary there are gotchas at every level from hardware bugs, compiler bugs, programming errors, incorrect configuration, and who knows what else that impair the programmer's ability to understand the actual semantics of the programming environment. When you add to that the potential for maliciously clever modifications such as the one in the Thompson paper along with the undeniably large benefit to any number of parties that might wish to compromise same, the only rational conclusion is that no computing system deserves to be trusted in itself. I don't trust other levels of the alleged chain of trust either. For example I consider it an absolute certainty that every competent globally active intelligence agency in the world has assets inside Facebook and Google, and most likely others. The cost and difficulty of inserting or recruiting an asset is so low and the potential benefits are so high that it's certain to have happened and in fact already has[1]. By the way while my ex-NSA buddy didn't elaborate on what he meant by attacking the implementation, but I'm pretty sure that includes subverting an implementer. Edit: I don't think we really substantially disagree, the above is meant to be elaboration not rebuttal. [1] https://www.washingtonpost.com/world/national-security/nsa-infiltrates-links-to-yahoo-google-data-centers-worldwide-snowden-documents-say/2013/10/30/e51d661e-4166-11e3-8b74-d89d714ca4dd_story.html https://www.washingtonpost.com/world/national-security/nsa-i...

User23 6y ago

It's possible to provably construct a program that will halt. That is the whole point of loop invariants. Similarly it is possible to provably construct a "secure" program up to physical limitations. However in both cases it requires that the semantics of the programming environment are known to the programmer. Even without a malicious adversary there are gotchas at every level from hardware bugs, compiler bugs, programming errors, incorrect configuration, and who knows what else that impair the programmer's ability to understand the actual semantics of the programming environment. When you add to that the potential for maliciously clever modifications such as the one in the Thompson paper along with the undeniably large benefit to any number of parties that might wish to compromise same, the only rational conclusion is that no computing system deserves to be trusted in itself. I don't trust other levels of the alleged chain of trust either. For example I consider it an absolute certainty that every competent globally active intelligence agency in the world has assets inside Facebook and Google, and most likely others. The cost and difficulty of inserting or recruiting an asset is so low and the potential benefits are so high that it's certain to have happened and in fact already has[1]. By the way while my ex-NSA buddy didn't elaborate on what he meant by attacking the implementation, but I'm pretty sure that includes subverting an implementer. Edit: I don't think we really substantially disagree, the above is meant to be elaboration not rebuttal. [1] https://www.washingtonpost.com/world/national-security/nsa-infiltrates-links-to-yahoo-google-data-centers-worldwide-snowden-documents-say/2013/10/30/e51d661e-4166-11e3-8b74-d89d714ca4dd_story.html https://www.washingtonpost.com/world/national-security/nsa-i...