absolutely no proof it is e2e encrypted without the source.
Later:
Also? That's not what the term "side channel" means.
i think this is why source is a must. if a user compiled and installed the app themselves, and hypothetically had the entire stack above it be similarly open, then it would prevent the kind of attack mentioned.
do you agree?
if the source is closed anywhere in the stack, or pushed out in a walled garden as it is currently, then it allows the vulnerability mentioned.
But I think you're a little confused here.
The cryptographic building blocks of the new WhatsApp protocol are available in source code. You can get source for the Signal Protocol (fka Axolotl). You can get source for the Noise framework. WhatsApp borrowed these tools from a very open secure messaging project.
You're unhappy that the source code for the fully assembled messaging product WhatsApp isn't available. I understand that, too.
But you've overplayed your hand by arguing that not releasing WhatsApp source is fatal to its security. Even if WhatsApp had done that, the overwhelming majority of its users (in fact: basically all of them) would be installing binaries. If WhatsApp is so evil that they've backdoored their product, it is "supervillain monologuing for an hour while the hero escapes"-grade stupid to leave that backdoor in their source code. Consider that carefully when you trust binaries from open source companies, by the way!
In reality, source code does very little to resolve the government backdoor problem. If you want to ensure that your secure messenger hasn't been backdoored, reverse engineer and/or instrument the build you're actually running.
Nobody does this, of course. But while lots of people glance at source code for crypto applications, I think they're pretty much just kidding themselves. Having the source code makes them feel safer, but it doesn't actually make them safer.
Every Linux distribution out there compiles everything in their repo by hand. If you use an AUR package of almost everything on Arch, you are building the software by hand locally from source. You can pull build scripts from launchpad, the Suse OBS, or almost every distros package repository (they all have automated build systems for everything, and you can do it all yourself).
Oh, and there is a little distro called Gentoo some people use where you literally build everything from source yourself.
So nobody builds open source software from source, besides the millions of people who do it all the time. Sure, it is a tiny fraction of total users, but there is a dramatic difference between "nobody" and "somebody" just like there is a dramatic difference in confidence between "were using this secure crypto, trust us, its there! its not just something else masquerading as secure crypto that we have backdoors all over!" versus "here is the source, go build it yourself if you don't trust us".
The value is not in everyone building from source themselves, just like my confidence in my software is not in auditing every line myself. It is in the general freedom of information on the security, and by offering the information to test it myself I will have inherently more trust in a project even if I never take advantage of that source availability myself - even if nobody ever does find exploits in the disclosed code, there is still trust a proprietary vendor can never have that I implicitly give free software projects because it is much more precarious to backdoor transparent software than a black box, and by just making the box transparent at all you add value.
That's what happened when Snowden started talking to Greenwald. Unfortunately, because our field is completely incoherent about security, instead of using a secure messenger, they used Cryptocat. Oh, the source code for Cryptocat was easy to get at, by the way! Didn't do much to keep those messages safe.
is there any way to verify that they actually use (an implementation of) this in their builds ? there's only one client, and I presume we can't make a third-party client to show it's interoperable with their implementation of the axolotl code.
Reproducible builds[1] are the solution to that problem. Everyone doesn't have to build the source if a) building the source produces the exact same binaries every time, and b) source can be built by a trustworthy party to verify that it matches the build being distributed. This way, you only need one good build cop to warn the rest of the population about bad binaries.
Signal for Android supports reproducible builds[2] so it seems entirely possible an open source WhatsApp client could as well.
[1]https://reproducible-builds.org/
[2]https://github.com/WhisperSystems/Signal-Android/wiki/Reprod...
Also, Apple's push messaging subsystem gets a copy of (most) of the message too so Apple could be doing evil things there too!
OH NOES!
>If WhatsApp is so evil that they've backdoored their product
Unless they want to go the way of Lavabit, every company is evil when kindly asked to be. (Well, maybe it helps when you have the weight of Apple, but that wasn't even a NSL if we heard about it.)
>it is "supervillain monologuing for an hour while the hero escapes"-grade stupid to leave that backdoor in their source code.
And if they don't, a reproducible build process will cause someone to notice the binary doesn't match up and sound the alarm, somewhat similar to how a warrant canary works even if not everyone is checking it. (Sure, the company could always go back on their open source promise for other reasons, but at least everyone is left with a last known-likely-good inspectable and forkable version.)
Try clicking on the timestamp for the comment when you have this trouble. A reply box should appear.
I implore you to do so. Post haste.
Reverse engineering binaries is only permitted under the DMCA for the purpose of interoperability, AFAIK.[1] If so, that would make reverse engineering to verify stated security claims illegal in the United States. I'll just assume I'm wrong here for the sake of argument though.
Reverse engineering sounds much less friendly than providing actual source code. It's much easier for me to compare changes from version to version with source control, commit comments, and diffs. Then all I need is a reproducible build to verify that the output matches the binary being shipped.
Do you have some reverse engineering tools you would suggest? Obviously the one's I'm familiar with are not as good as yours. Links to those would be greatly appreciated.
[1]https://www.eff.org/issues/coders/reverse-engineering-faq
I think this is losing sight of what source code actually is. It's the easier to read and easier to edit way to define what a person wants the computer to do. But, it isn't actually the exact instructions the computer executes.
They're using the Signal protocol, which has been well-vetted.
What I've seen so far in Wireshark looks good, but I am not a crypto expert. I'm in the process of reading and trying to understand the whitepaper[0] now.
I doubt OpenWhisperSystems would condone the use of WhatsApp without verifying the app uses e2e.
[0] https://www.whatsapp.com/security/WhatsApp-Security-Whitepap...
EDIT: Spelling.
With all the wonderful reverse-engingeering tools, dissassemblers, debuggers, etc. available, and the numerous massive communities that use them, it seems pretty out-there that you could seriously think such a thing...
[0] https://www.eff.org/deeplinks/2014/11/scorecard-update-we-ca...
And would you also claim that without the source, you can't find security problems?
A smart comment would be a detailed analysis of the pros and cons of OpenSource in terms of verification. Your are barly more then a troll.