undefined | Better HN

0 pointsCUViper12y ago0 comments

Why not? If you're being so paranoid about the origin of a binary, you have to at least acknowledge the fact that you're trusting the compiler in making this comparison.

So let me throw out an idea that might help justify this trust too. Compile the same TrueCrypt sources with a totally different compiler, then use both binaries in a deterministic way and compare the raw encrypted result. (I'm assuming here that the same encryption keys and data will give the same result, but don't know for sure if that's true.)

0 comments

13 comments · 6 top-level

jlgreco12y ago· 6 in thread

Create a piss-poor barebones compiler (compiler A) by hand (literally, if possible. punchcards would allow you to hand-verify the contents of the program in a way that is not susceptible to Thompson's attack (there is no risk that your eyes were built with a compromised compiler)) that suffices to compile a compiler that you want to verify (compiler B). Compiler A should to run on hardware that you can trust (need not be x86).

  (= ((a-binary b-source) b-source) b-binary)

If you trust a-binary, and you trust b-source, then if that returns true you should be able to trust anything created with b-binary. (a-binary b-source) will not equal b-binary, but ((a-binary b-source) b-source) should.

If the hardware is not executing binaries as described, then all bets are off. Compiler A could, in theory, be build and run on a homebrew CPU (http://www.homebrewcpu.com/), but if you are putting that much effort into this, this better be your hobby...

sliverstorm12y ago

Let's not forget you need to verify by hand the electrical characteristics & functionality of every logic chip you use to build that homebrew CPU, because the supply chain of basic logic chips is already known to be infected (primarily a QA issue, but clearly a potential vector)

tedunangst12y ago

Don't forget the power company. They can cause "spurious" bit flips by momentarily dropping the voltage at just the right instant. Best to use a battery made from potatoes you've grown yourself.

3 more replies

jlgreco12y ago

True, though I suspect you are going to be doing that already since you will undoubtedly fuck up your homebrew CPU in novel ways many times while building it, and spend many hours debugging each piece of it. ;)

edwintorok12y ago

Good reference on this technique: http://www.dwheeler.com/trusting-trust/

X412y ago

Do you suggest to apply the Bayes' theorem to verify the result's validity? As compilers: TCC, LLVM Clang and GCC come into my mind.

jlgreco12y ago

If all of those compilers share an ancestor compiler (in other words, if we think GCC is compromised and if Clang was originally bootstrapped with a compromised GCC), then I don't think that would be effective (although code that 'infects' not just future compilers of the same family (GCC that 'infects' future GCC's) but also any future compiler would be incredibly clever, to put it mildly).

Even if that were not the case, if the hypothesis is that GCC was compromised at some point in the past by a shadowy organization, then you have to consider the possibility that this shadowy organization also got to the other compilers. I think that is where probability steps in though; how confident are you that at least some of the compilers are still safe (or perhaps, at least compromised in conflicting ways)?

1 more reply

tripzilch12y ago· 1 in thread

> If you're being so paranoid about the origin of a binary, you have to at least acknowledge the fact that you're trusting the compiler in making this comparison.

Which the author does, in fact:

"Of course, we need to trust the compiler, but in this case, it is independent of TrueCrypt."

He even links to the "trusting trust" article.

CUViperOP12y ago

Ah, indeed, I didn't read closely enough to see that mention.

quasque12y ago

You wouldn't just have to verify if it produces the same encrypted output, but also if all the steps along the way are carried out in precisely the same manner. A compromised version of TC may correctly encrypt the volume as expected, but also leak the key or the encryption password on the sly.

lmm12y ago

If I wanted to compromise TrueCrypt via a secret compiler-injected vulnerability, I'd replace the key generation logic with something that used maybe 64 actually random bytes as the input to an unpublished high-quality PRNG (the NSA almost certainly has a few of those hanging around). I don't think you could detect that by your method.

sliverstorm12y ago

Why not?

Because TrueCrypt is several orders of magnitude more high-profile of a target (being actual cryptography instead of a compiler) and probably also several orders of magnitude easier to compromise in a useful fashion & spread.

Paranoia is without bound. Who knows, you yourself might be a sleeper agent and you just don't know it yet! Maybe your eyes really were compromised in development! So you approach the problem from the point of view of what is likely, and what is not. You cannot guard against every single paranoia, but you can guard against ones you deem more likely.

pyre12y ago

See: https://news.ycombinator.com/item?id=6608922

The compiler backdoor would have to be very old to exist.

j / k navigate · click thread line to collapse

0 comments

13 comments · 6 top-level

jlgreco12y ago· 6 in thread

  (= ((a-binary b-source) b-source) b-binary)

sliverstorm12y ago

tedunangst12y ago

Don't forget the power company. They can cause "spurious" bit flips by momentarily dropping the voltage at just the right instant. Best to use a battery made from potatoes you've grown yourself.

3 more replies

jlgreco12y ago

edwintorok12y ago

Good reference on this technique: http://www.dwheeler.com/trusting-trust/

X412y ago

Do you suggest to apply the Bayes' theorem to verify the result's validity? As compilers: TCC, LLVM Clang and GCC come into my mind.

jlgreco12y ago

1 more reply

tripzilch12y ago· 1 in thread

> If you're being so paranoid about the origin of a binary, you have to at least acknowledge the fact that you're trusting the compiler in making this comparison.

Which the author does, in fact:

"Of course, we need to trust the compiler, but in this case, it is independent of TrueCrypt."

He even links to the "trusting trust" article.

CUViperOP12y ago

Ah, indeed, I didn't read closely enough to see that mention.

quasque12y ago

lmm12y ago

sliverstorm12y ago

Why not?

pyre12y ago

See: https://news.ycombinator.com/item?id=6608922

The compiler backdoor would have to be very old to exist.

j / k navigate · click thread line to collapse