Also, message metadata is still being leaked by all of these E2E implementations and needs to be fixed.
I mean, sure, there could be "Whatsapp clones" (aren't there already?!), but wouldn't Whatsapp still benefit from the phone number user base it has, thus maintaining a certain lock-in on its users from which it already benefits?
Sounds funny if you consider that Whatsapp itself is just a branded deployment of FOSS XMPP server Ejabberd, with feature of federation taken away. Plus a client app implementation, of course.
Nothing in the AGPL prevents either from occurring.
No idea whether the assumption is true that Whatsapp is just a branded deployment.
As the countless messaging apps out there demonstrate, the value of communication apps lies in the network they build. If they provide a decent UX, and successfully bootstrap a network large enough, it wont matter if their code is open.
you replace Whatsapp.sendMessage(string,Jonny) with WhatsApps.sendMessage(EncryptString(string,Jonny),Jonny)
And EncryptString taps into your keystore to find jonny's key.
Ricochet (https://ricochet.im/) solves that problem using Tor hidden services. Desktop only at the moment AFAIK, though.
Appears to have a lot of docs/code, are you able to link to the related code & docs?
This zealous belief that all secure cryptography must be open source is something I hear a lot from open source advocates, but not so much from cryptography engineers.
It's the exact same code we use in Signal: https://github.com/whispersystems/libsignal-protocol-java
You are better off verifying the actual compiled and distributed apk files than verifying the source.
For an example of a more sophisticated approach, look at:
Remember, in this case, it's especially easy to reverse, because you have the source code; all you're doing is matching the control flow graph to the original source.
I imagine I won't ever get to it, but that sounds like an interesting problem to try to work on.
[To whomever down voted... I guess I get down voted for not showing gratitude immediately after he posted a reply? This is why I don't post here often. Quite mean people here.]
I think it's great when people further verify WhatsApp's client security, please share your analysis!
My primary concern here is a long con. Everything is probably okay now, but after a while, people will stop looking and verifying. With WhatsApp keeping source closed, it makes that period of time shorter, I think. I will try to work your suggestion into my job :) If I'm paid to do it, I can keep doing it indefinitely, even working on tools to automate it.
Could you cite this? The Signal Protocol implementations they're using are both open source and well audited.
By that logic the entire application would need to be open source, because nobody would start out by targeting the crypto if they wanted to spy on someone.
But you need far more than just the crypto code to create a client, I think open source protocol specs would already achieve this.
And my main complaint was with the claim that open sourcing their crypto code would somehow make a meaningful difference to the security of these applications to the extent where you could consider all applications that haven't done so "insecure".
Without open-sourcing the crypto, they could be just doing rot16($message) for all we know. Open-source is a requirement for being considered secure. It doesn't mean they aren't secure if they aren't open-source, but that you shouldn't consider it so, because you don't know if it is or not.
> Without open-sourcing the crypto, they could be just doing rot16($message) for all we know.
There are two things you can do:
1. Watch the outbound traffic and attempt known-plaintext attacks
2. Reverse engineer the app
Neither is particularly difficult. Most Android apps are trivial to break apart using Lobotomy. A large swath of software security folks specialize in binary auditing.
https://github.com/tgalal/yowsup for example
https://gigaom.com/2015/01/20/whatsapp-cracks-down-on-people...
Do you know if the clients work with the new encryption?
What I find ridiculous though was
>venders that don't agree to an audit should be considered insecure
The same thing applies to every single part of the application, but not equally. No attacker is going to start out by trying to break the crypto, unless it's obviously broken. "Normal" bugs are far more common and often more dangerous (Thing RCE, or in the case of many modern apps: XSS)
Emphasis mine. I agree with ryanlol here. Why bother with active attacks when you can just steal their private key from a code execution?
Similar to this, but with the priority flipped:
https://www.bishopfox.com/blog/2016/04/if-you-cant-break-cry...
The second problem is - you don't know if that source is what ended up in the binary.
So yeah, unless you can compile the whole thing yourself, it should not be considered secure.
It's not a high bar.
https://www.bishopfox.com/blog/2016/04/if-you-cant-break-cry...
So, my point that the E2E should be open source is that that code should never be the basis for a business model, so to me, it being open source makes sense. As larger system, that's why I'm saying there needs to be an audit.
Also, you mentioned ATP and I agree, which is why to me it is troubling Signal instead of guarding metadata, actively collects it.
Please let me know I have missed anything you'd like me to address. And I really would be interested in your thought on the question above in as much detail as you're able to share. Thanks!