[nnnnnn]

Without whatsapp being open source, how do we know for sure that Facebook is not somehow storing or reading our messages?

As good as this sounds on paper, I hesitate to trust Facebook to transmit my data without wanting to peek a bit. I currently use both Whatsapp and Signal and will probably continue to do the same unless there is a way for users to verify Facebook doesn't keep a copy.

[tptacek]

Closed source software isn't impenetrable. The idea that you need source code to evaluate security claims is mostly a meme from the 1990s.

[dest]

Taking the example of Skype, the hardening/on-the-fly decryption techniques used in the binary made the reverse engineering very difficult [0]. Difficult to reliably audit such software. Don't know about Whatsapp though.

[0] http://www.oklabs.net/skype-reverse-engineering-the-long-jou...

[tptacek]

That was true in the case of Skype (which was eventually reversed), but it is not true here.

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

[wyager]

You don't need the source, but it makes it a hell of a lot easier.

[tptacek]

Only if builds are fully reproducible, which is rarely true. Otherwise, the source can make it harder, by lying to you.

[wyager]

Don't tell me that it's easier to RE an entire multi-megabyte messenger app than it is to real the source code. Assembly can lie to you as well. There are all sorts of ways to trick IDA and friends.

[kbwt]

Then demand reproducible builds from software with security claims?

[tptacek]

Can I have serious cryptanalytic audits first? Because virtually nothing has that. At least I trust what Signal Protocol is trying to do!

[kbwt]

One does not preclude the other. For instance, the current Signal implementation is almost certainly prone to remote code execution.

How does the Signal project handle reports of potential vulnerabilities? I haven't seen any security contact information on the OpenWhisperSystems site.

[jamesdwilson]

how's that boot taste?

[dang]

I realize you've gotten hammered by downvotes already, but this comment crosses the additional (and much worse) line of personal attack. Please don't do that on HN, regardless of who you're disagreeing with or how wrong they may be.