[dest]

Maybe it is feasible, but at the very least I would wait for someone to reverse engineer it and publicly publish its findings. I do not have the skills to do that.

Moreover, if reverse engineering is so easy, why not open-source it from the beginning?

[tptacek]

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!

I think the misconception some people here have about the necessity of source code is born out of the idea that a cryptographic backdoor would look something like a mysterious HTTP POST of your key or plaintext to some random endpoint (that POST, by the way, would be trivial to spot in the binary; you wouldn't even need to read assembly).

But real cryptographic backdoors can be extremely difficult to spot. A cryptographic algorithm that uses signatures, for instance, can be fatally compromised by breaking signatures (see: TLS). An injected cryptographic flaw that breaks signatures can be as simple as biasing a single-digit number of bits in a nonce; a bias can be as subtle as generating one less byte of randomness than the protocol requires.

[codys]

> 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.

[kasey_junk]

I think the argument (one I'm not expert to make) is that the source may or may not be helpful to someone who is competent enough to validate a encrypted message application, but it is not what you need to verify.

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.

[tptacek]

Yep. I don't think source is a bad thing! It's good to have, but it isn't the predicate people on this thread were saying it was.