4 ms·

> Mistrust of commercial solutions does not translate into trust for open-source ones. Well, how well can you trust the commercial ones ? At least with open so

by jokoon 13y ago

> Mistrust of commercial solutions does not translate into trust for open-source ones. Well, how well can you trust the commercial ones ? At least with open source, you can look into it more easily and eventually find security holes. It's a step towards trust. There is no trust to gain with commercial solutions, but at least with open source, it's at least possible. The fact that proprietary agrees with a sound market economy makes it somehow more functional and more attractive, but when you're concerned about ethics, it's a totally other concern.

acqq 13y ago
how well can you trust the commercial ones ? At least with open source, you can look into it more easily and eventually find security holes. It's a step towards trust. There is no trust to gain with commercial solutions, but at least with open source, it's at least possible. Ever heard of reverse engineering? It turns out you'd need even that approach even with open source as soon as you use binaries you haven't compiled yourself. And you'd have to verify the compiler and your disassembler that way too. It's all possible, but requires more than it's currently being done, at least on the level of the stuff openly available. And even if you manage to verify everything you have to check the computer. Modern computers be it servers or notebooks start to have BIOS-es that can even phone home and allow remote access without your control (having the keys which you can't control!).
- dllthomas 13y ago
  "Ever heard of reverse engineering? It turns out you'd need even that approach even with open source as soon as you use binaries you haven't compiled yourself." This is true: reverse engineering can be used for verification, but it's a whole lot more work than inspecting source. "And you'd have to verify the compiler and your disassembler that way too." This is false. You can verify the compiler with diverse double compiling: http://www.dwheeler.com/trusting-trust http://www.dwheeler.com/trusting-trust
  - acqq 13y ago
    Am I missing something: does it mean that to verify the compiler with DDC you need a trusted compiler that always produces the same binary output as an untrusted one, so to verify GCC you need a compiler that duplicates the whole GCC functionality but is trusted? What is practicality of that approach? Proving that "hello world" produces the same output doesn't prove that the crypto functions wouldn't be patched? Please a specific example of what would be needed to prove GCC and LLVM now. EDIT: I'm not interested in toy compiler and theoretical pie-in-the-sky examples, I want to know how practical it is for the systems in real use. GCC and LLVM as they are now please. If the proposition is "suppose that we have something that can compile gcc sources and we trust it" tell me what is that, does it exist and how hard would it be to make it. Don't talk to me about your experiment where you change one line in TTC and then prove it's changed by comparing the binaries.
    - dllthomas 13y ago
      You're missing something. The idea is to take one compiler source (S), and compile it with a diverse collection of compilers (Ck being a compiler in C0-CK), producing a diverse collection of binaries that are compilations of S: (Bk = Ck(S)). Because the different compilers are almost certainly not functionally identical, the various Bk should not be expected to be bitwise identical. However, because they are compilations of the same source, they should be functionally identical, or one of the original compilers was broken (accidentally or deliberately). So now we can compile that original source with the Bk compilers, and because these compilers are functionally identical, the results (Bk(S))should be bitwise identical. There is certainly some chance of false positive, due to bugs in the Ck compilers or exploitation of undefined behavior in S, but if you do get the same output (Bk(S)) from all of the (Bk) compilers then you can be pretty confident that there is no Trusting Trust style attack present: exceedingly so, when the various compilers have diverse histories so that it's exceedingly unlikely that all Ck compilers contain the same attack. If there are any differences, you can manually inspect them to determine what the issue is and either issue a bug report to the appropriate compiler, change the source (S) to avoid undefined behavior, or notify people of the attack present in the compiler in question, depending on what you find. This does involve some binary digging, but quite targeted compared to a full audit and it may well not be necessary at all. Obviously, if you do have a trusted compiler, including it in the mix is great, but the technique doesn't rely on this, nor on any two compilers returning the same binary output except when they are compilations of the same source.
- jokoon 13y ago
  You seem quite paranoid. Open source was thought to sweep away for hidden code, I really doubt GCC or other compilers has that special code that is reproduced each time you recompile a compiler with it. If there was such self-reproducing code in a compiled GCC, it would be quite easy to find. There are many eyes looking at a program like GCC. And even with such a conspiracy theory, which is still possible, open source has better margin than proprietary. It's not perfect, but it's much more transparent if you get what I mean.

by jokoon 13y ago

acqq 13y ago

how well can you trust the commercial ones ? At least with open source, you can look into it more easily and eventually find security holes. It's a step towards trust. There is no trust to gain with commercial solutions, but at least with open source, it's at least possible. Ever heard of reverse engineering? It turns out you'd need even that approach even with open source as soon as you use binaries you haven't compiled yourself. And you'd have to verify the compiler and your disassembler that way too. It's all possible, but requires more than it's currently being done, at least on the level of the stuff openly available. And even if you manage to verify everything you have to check the computer. Modern computers be it servers or notebooks start to have BIOS-es that can even phone home and allow remote access without your control (having the keys which you can't control!).

dllthomas 13y ago
"Ever heard of reverse engineering? It turns out you'd need even that approach even with open source as soon as you use binaries you haven't compiled yourself." This is true: reverse engineering can be used for verification, but it's a whole lot more work than inspecting source. "And you'd have to verify the compiler and your disassembler that way too." This is false. You can verify the compiler with diverse double compiling: http://www.dwheeler.com/trusting-trust http://www.dwheeler.com/trusting-trust
- acqq 13y ago
  Am I missing something: does it mean that to verify the compiler with DDC you need a trusted compiler that always produces the same binary output as an untrusted one, so to verify GCC you need a compiler that duplicates the whole GCC functionality but is trusted? What is practicality of that approach? Proving that "hello world" produces the same output doesn't prove that the crypto functions wouldn't be patched? Please a specific example of what would be needed to prove GCC and LLVM now. EDIT: I'm not interested in toy compiler and theoretical pie-in-the-sky examples, I want to know how practical it is for the systems in real use. GCC and LLVM as they are now please. If the proposition is "suppose that we have something that can compile gcc sources and we trust it" tell me what is that, does it exist and how hard would it be to make it. Don't talk to me about your experiment where you change one line in TTC and then prove it's changed by comparing the binaries.
  - dllthomas 13y ago
    You're missing something. The idea is to take one compiler source (S), and compile it with a diverse collection of compilers (Ck being a compiler in C0-CK), producing a diverse collection of binaries that are compilations of S: (Bk = Ck(S)). Because the different compilers are almost certainly not functionally identical, the various Bk should not be expected to be bitwise identical. However, because they are compilations of the same source, they should be functionally identical, or one of the original compilers was broken (accidentally or deliberately). So now we can compile that original source with the Bk compilers, and because these compilers are functionally identical, the results (Bk(S))should be bitwise identical. There is certainly some chance of false positive, due to bugs in the Ck compilers or exploitation of undefined behavior in S, but if you do get the same output (Bk(S)) from all of the (Bk) compilers then you can be pretty confident that there is no Trusting Trust style attack present: exceedingly so, when the various compilers have diverse histories so that it's exceedingly unlikely that all Ck compilers contain the same attack. If there are any differences, you can manually inspect them to determine what the issue is and either issue a bug report to the appropriate compiler, change the source (S) to avoid undefined behavior, or notify people of the attack present in the compiler in question, depending on what you find. This does involve some binary digging, but quite targeted compared to a full audit and it may well not be necessary at all. Obviously, if you do have a trusted compiler, including it in the mix is great, but the technique doesn't rely on this, nor on any two compilers returning the same binary output except when they are compilations of the same source.
jokoon 13y ago
You seem quite paranoid. Open source was thought to sweep away for hidden code, I really doubt GCC or other compilers has that special code that is reproduced each time you recompile a compiler with it. If there was such self-reproducing code in a compiled GCC, it would be quite easy to find. There are many eyes looking at a program like GCC. And even with such a conspiracy theory, which is still possible, open source has better margin than proprietary. It's not perfect, but it's much more transparent if you get what I mean.