> If you have the source then you can see what it does. What if it exploits a compiler bug to do something different than it looks? What if the compiler recogn

> If you have the source then you can see what it does. What if it exploits a compiler bug to do something different than it looks? What if the compiler recognizes the code and instruments it with its backdoor? Sure, GCC probably doesn't, but what if the code was meant for Windows and only builds under MSCV which you can't audit? What if the code exploits an undocumented “feature” in Intel x86 processors? What if it uses a backdoor in Intel's randomness hardware? Modern Intel processors have many undocumented features and essentially can do whatever the hell they want with your code. The NSA almost certainly has a backdoor in Intel's RDRAND[1]. x86(_64) is impossible to trust; even VIA CPUs may be compromised (though they lack the “management engine” of Intel and AMD—if I were to 100% audit a crypto-related program that only runs on x86, I would use a VIA system and intercept any instructions that use the hardware RNG). Point is, open source makes some things vastly easier, but the point is you _need_ to audit the binary anyway. That's the _only_ way to trust it. You _cannot_ trust the source code. You cannot even trust a machine other than POWER, RISC-V, or SuperH/JCore. If you're not going to be paranoid as all hell, auditing crypto is pointless. 1. http://arstechnica.com/security/2013/12/we-cannot-trust-intel-and-vias-chip-based-crypto-freebsd-developers-say/ http://arstechnica.com/security/2013/12/we-cannot-trust-inte...