| > If you don't have the skills to do basic verification of a non-obfuscated binary, you don't have the skills to verify an encrypted messaging protocol implementation from source either: the latter task is harder than the former! Those aren't quite the same skill though. Some folks could have the skills to verify protocols from source, but not the skills to work with a non-obfuscated binary. Task 'A' being harder than task 'B' doesn't mean that everyone who can do 'A' (harder task) is capable of 'B (easier). Nor does the inverse follow at all. If we admit that doing basic (non-messaging protocol impl) verification on a binary is difficult and doing messaging protocol impl verification is also difficult, it seems reasonable to presume that doing both will take more time, work, and as a result, allow for more errors in verification. Essentially, verifying impls without source code is more difficult/time consuming/error prone than verifying ones with source code. Of course, they could give someone the source code to verify without making it open source. But that requires that one trust this other party, selected by folks who have an interested in their protocol being reported as secure (whether it is or not). The goal when folks are looking for freely available source code is to eliminate some of those needs for trust (by allowing a greater number of verifiers) and eliminate some of the conflict of interest (by removing some control the interested party has). Sure, closed source bits that promise to be good and that we can (potentially) look at are OK. But having source code for them is still better. |
You must verify the binary because you cannot trust the source, so it is a basic skill of anyone who has the competency to validate an encrypted message application.
Now, its possible, that the source along with repeatable builds make verifying the binary easier for someone with the skills necessary, but even with those things, they still have to verify the binary.