Let's not forget Signal is FOSS and has reproducible builds (https://signal.org/blog/reproducible-android/). This makes it far easier to trust its verification code.
Another interesting extension of reproducible builds: https://wiki.mozilla.org/Security/Binary_Transparency
I'm no Android or iOs dev, so I might be wrong, but to my knowledge there is no feature to push an app update specifically to a narrow set of devices?
So at the very least, third parties (Apple/Google) would have to be involved in such an attack. This removes some entities from the list that could create an attack.
Also, Apple/Google have a big reason not to play such games. Their app stores are partially so popular because they, as companies, are trusted. Apple/Google would only do this if they'd be legally required to. IF they were involved, even against their will, this would mean tremendous risk to trust in these companies, meaning risk to the stock. And for a publicly traded company, there is no bigger motivator. Apple/Google would get out all the lobbying power they have, trying to fight off whatever coercion tool the US government uses against them to make them comply.
Even if there'd be no opposition from Apple or Google, people outside would notice sooner or later that they've got malicious updates. If they use it once or twice, they might go undetected, but if governments or other entities start using this as a vector repeatedly, it will get to the public.
This doesn't mean that I think that these issues aren't important. Reproducible builds, binary transparency, gossip protocols, all these things are very important areas to invest research in, but right now they aren't a vector that is being abused on observable scales.
Yes, it's possible to target "narrow set of devices" by using Device Catalog. An excerpt from the ToS:
> Google Play Console Device Catalog Terms of Service
> By using the device catalog and device exclusion tools in the Play Console (“Device Catalog”), You consent to be bound by these terms, in addition to the Google Play Developer Distribution Agreement (“DDA”). If there is a conflict between these terms and the DDA, these terms govern Your use of the Device Catalog. Capitalized terms used below, but not defined below, have the meaning ascribed to them under the DDA.
> 1. The Device Catalog allows You to review a catalog of the Devices supported by Your app and search the Devices by their hardware attributes. It also allows You to exclude specific Devices that are technically incompatible with Your app.
I wasn't aware of Binary Transparency, thanks! A cool idea, akin to Certificate Transparency.
So Signal can learn who talks with whom via requests going through their LDAP-like server. They can get an idea how long calls are, and if it was a vid or audio call. They know the times of communication.
You know, they can see the metadata. When's the last time we had problems with metadata? The POTS network? Yep.
And you're indeed right the client has reproducible builds. But the server side certainly doesn't. And we have no way to ascertain that.
Yes, metadata is a problem, particularly with calls. However, Signal recently added the sealed sender (https://signal.org/blog/sealed-sender/) feature which makes the server blind to who the sender of a message is.
> And you're indeed right the client has reproducible builds. But the server side certainly doesn't.
That's true, but the server side is much less important when it comes to cryptographic assurances.
Signal is definitely not a panacea, but by many counts it's better than anything else that currently exists and has any semblance to something a typical user can use.
> We’ve designed the Signal service to minimize the data we retain about Signal users, so the only information we can produce in response to a request like this is the date and time a user registered with Signal and the last date of a user’s connectivity to the Signal service.
https://signal.org/bigbrother/eastern-virginia-grand-jury/
This was even before sealed sender, so if anything my confidence in the Signal Foundation has only increased.
Now, protecting everyone's meta data is hard (probably impossible), and I don't mean to be defeatist - but "it's just metadata" doesn't sit well in a post Snowden world. We know all large intelligence agencies hoover up this stuff.
And we also know that agencies are made up of people, and some people abuse their access.
To suggest that metadata of communication over Signal between my spouse and I will be used against my grand kids one day is a bit absurd though. Of course there’s tons of metadata connecting my spouse and I. It would be more suspicious if there wasn’t.
If a friend turns out to be union organizer, you might be banned from jobs, if the government decides to collude with employers (again).
Like a lot of things it boils down to your threat model. If the broker or a state are your adversary, it wouldn't need to be a general design feature to behave this way but it could instead target you at the time of key exchange. Not an implausible scenario for reporters and their sources, e.g.
Those folks are especially vulnerable because they might be led to believe claims of "end to end encryption". Put that together with those default settings and interception and impersonation can happen right under your nose.
Maybe the client itself is generating the keypair. In this case, the only issue I can see is the following: when the user wants to communicate with a friend, how can they be sure that the profile they are sending messages to (as displayed by their user interface and communicated by Facebook or Whatsapp or the friend's server) actually do belong to their friend?
I'm confused what you were talkimg about, with the client build possibly being a trojan
That's exactly the point though, how can they be sure in the event that their client (on the author's side) is a trojan? If the "author" client is deliberately compromised, there is no longer any reasonable means of ensuring that the public key the author uses to encrypt the messages is actually equal to the public key the recipient published.
Of course, this point is very much riddled with paranoia: it is exceedingly unlikely that the WhatsApp client deliberately contains such a trojan, especially since there are much easier ways of gaining access to user's messages (such as compromising their firmware with some form of rootkit, possibly installed via the baseband, and then simply sending copies of the local message cache to the NSA).
If your looking to build software that integrates with Signal, then libsignal is great (having built a few things with it).
There have been some concerns with their security:
https://www.schneier.com/blog/archives/2016/03/imessage_encr...
https://www.pandasecurity.com/mediacenter/technology/need-kn...
https://www.tomshardware.com/news/imessage-weak-encryption-m...
Additionally, iMessage doesn't have any means of out-of-band key verification, so you actually have to trust Apple to faithfully exchange keys and there's no way to verify that it's done so.
iMessage also tells you after a message is sent (via the color of a bubble) whether the recipient received it using iMessage. That's not very good assurance if, say, you're messaging a journalist in an authoritarian country. Will it go out over SMS or iMessage? You can find out, but even a little bit of doubt about that can have significant consequences.
I'm glad iMessage does do encryption like it does, but it's no replacement for Signal and WhatsApp uses libsignal for its encryption.
Do you mean "you have to trust Apple"? I don't see what Facebook has to do with iMessage.
[EDIT: Now corrected above. Thanks!]
Who does that for every conversation? Or even once per week/contact?
Sort of.
Yes, they could serve you a MITM key, but it would be easily discoverable when you compare security codes in the client. And since the client is widely distributed on major app stores, it would be very risky to ship a compromised client.
Ultimately key exchange is a hard problem to solve. Notice that Signal doesn't do anything that much different; Signal does the key exchange and unless you verify each user's key offline, you have to trust it. Both WhatsApp and Signal have an option to display a notice when keys change, but Signal's is on by default.
Overall it's still pretty damn good. WhatsApp is perhaps the only major form of consumer communication where, by default and with no opt-out, every single chat really is fully encrypted using a widely respected protocol (libsignal). That's not nothing.