That's absolutely silly and gullible because of the following reasons:
1.) No, cryptography does not replace the trust in people. Your dead wrong if you think so. You need to trust the maker of the cryptographic software, whether it's open source or not, and even if the software has been audited. The only exception would be that you have team of experts who continuously audit the source code and compile every executable themselves. Then, of course, you can also just fork it and develop it yourself. Other than that, you better trust the source.
2.) I was explicitly talking about the binaries. The vast majority of all users will download the binaries and never check the source code. Moreover, if you check the source code, then this gives you no reason to trust the binaries.
Here's how I would do it, if I was working for an intelligence agency supplying bogus open source software: I'd put audited and correct sources on the web, but would make them hard to compile (e.g. complicated dependencies, tool chain setup). Then I would put binaries on the web page, too. And then I would check who downloads the software and based on some heuristics either deliver a perfectly fine web page+binary or a compromised web page+binary to the recipient, depending on whether I want to collect intelligence from that person or not.
Another, simpler method is to ensure that there is always some exploitable bug in the software. If that is found by external auditors, just introduce a new bug. The underhanded C contest shows you how it's done.
In any case, before you start talking about encryption again, we're talking about side channel attacks, of course.
1.) No, cryptography does not replace the trust in people. Your dead wrong if you think so. You need to trust the maker of the cryptographic software, whether it's open source or not, and even if the software has been audited. The only exception would be that you have team of experts who continuously audit the source code and compile every executable themselves. Then, of course, you can also just fork it and develop it yourself. Other than that, you better trust the source.
2.) I was explicitly talking about the binaries. The vast majority of all users will download the binaries and never check the source code. Moreover, if you check the source code, then this gives you no reason to trust the binaries.
Here's how I would do it, if I was working for an intelligence agency supplying bogus open source software: I'd put audited and correct sources on the web, but would make them hard to compile (e.g. complicated dependencies, tool chain setup). Then I would put binaries on the web page, too. And then I would check who downloads the software and based on some heuristics either deliver a perfectly fine web page+binary or a compromised web page+binary to the recipient, depending on whether I want to collect intelligence from that person or not.
Another, simpler method is to ensure that there is always some exploitable bug in the software. If that is found by external auditors, just introduce a new bug. The underhanded C contest shows you how it's done.
In any case, before you start talking about encryption again, we're talking about side channel attacks, of course.