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