5 ms·
Use your current version of openssl...
by j_walter 5y ago
Use your current version of openssl...
- ronsor 5y ago... and if your current version of openssl is already compromised, nobody can help you anyway.
- manquer 5y agoThere are always components you cannot fully trust . Ken Thompson's reflections on trusting trust [1] comes to mind Trust depends on threat model, if your threat model includes such actors/potential attack vectors then you should worry, ultimately you are depending on someone code for any reasonable abstractions (even ignoring chip level comprises) [1] https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustingTrust.pdf https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref...
- marcodiego 5y agoThere is a way out: a simple assembler that can be hand typed and easily checked that allows the user to type-in a more advanced one ... until a compiler or interpreter with checked source code can be run and bootstrap tools whose source can be checked by hashes. It is already doable: https://bootstrappable.org/ https://bootstrappable.org/ https://gitlab.com/janneke/mes https://gitlab.com/janneke/mes https://git.savannah.nongnu.org/cgit/stage0.git/tree/README.org https://git.savannah.nongnu.org/cgit/stage0.git/tree/README....
- manquer 5y agoThe point is not that it whether it is possible, it is not going to be practical, this you will always have some level of accepted risk. Even if you could ensure the compiler is secure, it is hard if not impossible to completely control what actually runs on the chip.
- marcodiego 5y agoYou can do it once in your life on a single machine. From there you compile the software for other machines. It is like a tree whose fruits you trust because you planted it yourself (actually it is more like if you wrote the seed yourself) and use it to plant other trees. Only remaining vulnerability is the hardware, but as I like to say: security is not binary.
- IncRnd 5y agoThat is not doable, given the threat discussed in the mentioned paper, since the manner of data entry and the manner of "easily checking" can be compromised. If you are hand typing an assembler in order to bootstrap a more complicated assembler, which creates a compiler or interpreter to check a single hash value, you are engaging in the wrong mitigation. You should instead use an airgapped computer with different software.
- marcodiego 5y agoAFAIK, the bootstrapable project specifically addresses the reflections on trusting trust problem.
- IncRnd 5y agoHow could it be addressed given this, "the manner of data entry and the manner of "easily checking" can be compromised"? That is the reflection upon trusting trust.
- marcodiego 5y agoI can't see where It fails... let's check... 1 - Somebody writes a very simple assembler that can be easily checked. 2 - I type-in that assembler from hex using specialized hardware for that purpose. What is typed is exactly what is turned into data unless hardware is compromised. 3 - From that assembler, I type-in a more advanced assembler that was checked by hand from more people and whose hash was hand-calculated. After that, I check its hash. Software on my machine can only be compromised if the people who wrote this more advanced assembler are compromised, I also check the hash to guarantee it was typed exactly. 5 - From this more advanced assembler I type-in the source code of a compiler or interpreter which was checked by more people and its hash was hand calculated. Same as before with regard to chances of being compromised. 6 - I can then bootstrap more advanced software whose source code I trust and I can check the source code was not tampered with with hashes. What step fails?
- IncRnd 5y ago
- cortesoft 5y agoThat doesn't protect against untrustworthy chips
- marcodiego 5y agoYes, but trust is delegated to hardware only instead of hardware and software.
- totetsu 5y agoGeneral AI existential crisis.. how can I trust my sense of trust?
- marcodiego 5y agoYou can reduce the number of parts you have to trust.