Google Criticized for 'Misleading' Encryption Claims About Its Text-Messaging App (daringfireball.net) 61
Google's app store claims that their text-messaging app Google Messages means "conversations are end-to-end encrypted".
"That is some serious bullshit," argues tech blogger John Gruber: It's shamefully misleading regarding Google Messages's support for end-to-end encryption... Google Messages does support end-to-end encryption, but only over RCS and only if all participants in the chat are using a recent version of Google Messages. But the second screenshot in the Play Store listing flatly declares "Conversations are end-to-end encrypted", full stop...
I realize that "Some conversations are end-to-end encrypted" will naturally spur curiosity regarding which conversations are encrypted and which aren't, but that's the truth. And users of the app should be aware of that. "RCS conversations with other Google Messages users are encrypted" would work.
Then, in the "report card" section of the listing, it states the following:
Data is encrypted in transit
Your data is transferred over a secure connection
Which, again, is only true sometimes. It's downright fraudulent to describe Google Messages's transit security this way.... [D]epending who you communicate with — iPhone users, Android users with old devices, Android users who use other text messaging apps — it's quite likely most of your messages won't be secure... E2EE is never available for SMS, and never available if a participant in the chat is using any RCS client (on Android or Apple Messages) other than Google Messages. That's an essential distinction that should be made clear, not obfuscated.
Gruber's earlier blog post had pointed out that the RCS standard "has no encryption; E2EE RCS chats in Google Messages use Google's proprietary extension and are exclusive to the Google Messages app, so RCS chats between Google Messages and other apps, most conspicuously Apple Messages, are not encrypted."
And in his newer post, Gruber adds, "While I'm at it, it's also embarrassing that Google Voice has no support for RCS at all. It's Google's own app and service, and Google has been the world's most vocal proponent of RCS messaging."
"That is some serious bullshit," argues tech blogger John Gruber: It's shamefully misleading regarding Google Messages's support for end-to-end encryption... Google Messages does support end-to-end encryption, but only over RCS and only if all participants in the chat are using a recent version of Google Messages. But the second screenshot in the Play Store listing flatly declares "Conversations are end-to-end encrypted", full stop...
I realize that "Some conversations are end-to-end encrypted" will naturally spur curiosity regarding which conversations are encrypted and which aren't, but that's the truth. And users of the app should be aware of that. "RCS conversations with other Google Messages users are encrypted" would work.
Then, in the "report card" section of the listing, it states the following:
Data is encrypted in transit
Your data is transferred over a secure connection
Which, again, is only true sometimes. It's downright fraudulent to describe Google Messages's transit security this way.... [D]epending who you communicate with — iPhone users, Android users with old devices, Android users who use other text messaging apps — it's quite likely most of your messages won't be secure... E2EE is never available for SMS, and never available if a participant in the chat is using any RCS client (on Android or Apple Messages) other than Google Messages. That's an essential distinction that should be made clear, not obfuscated.
Gruber's earlier blog post had pointed out that the RCS standard "has no encryption; E2EE RCS chats in Google Messages use Google's proprietary extension and are exclusive to the Google Messages app, so RCS chats between Google Messages and other apps, most conspicuously Apple Messages, are not encrypted."
And in his newer post, Gruber adds, "While I'm at it, it's also embarrassing that Google Voice has no support for RCS at all. It's Google's own app and service, and Google has been the world's most vocal proponent of RCS messaging."
They need to say it (Score:5, Funny)
Well this is just because the word is really nice and they need to be able to say it.
End to end encrypted... Otherwise only those that actual do it could say it and that would be bonkers!
Re:They need to say it (Score:5, Informative)
End to end encrypted... Otherwise only those that actual do it could say it and that would be bonkers!
Speaking as a security engineer focused on cryptography, basically none of the apps that claim end-to-end encryption are telling the truth except Signal, and there's a caveat there.
The problem is the servers that manage the key exchange. Your phone sends your public key to a server, which sends it to the other phone, and vice-versa. This is a perfect opportunity for the server to MITM the communications, especially if the actual messages also pass through the server (as is the case with iMessage, AFAIK). It's better if the server isn't actually involved in the message transfer (as is the case with RCS, since the "introduction" step is handled by Google servers but messages pass only between carrier servers), but only if you can guarantee that there's no collusion between introduction servers and message-passing servers.
The way to fix this is to do what Signal does: Allow users to compare fingerprints out-of-band. And, of course, this only works if enough users actually do it, and if it can be verified that the fingerprints being compared are those of the actual encryption keys, which basically requires it to be open source with reproducible builds (or deeply reverse-engineered). Signal meets both of those requirements, but AFAIK none of the other tools do. And most Signal users don't actually bother comparing fingerprints. Probably enough of them do that any shenanigans would be noticed, though.
Re: (Score:3)
If your 2 devices communicate directly, what happens if a router in the middle is compromised?
I'm now curious about your supposed "security engineer focused on cryptography" creds, because you have just demonstrated a pretty egregious lack of understanding of key exchange, asymmetric encryption, and how it protects from MITM with entirely open communications.
Re: (Score:3)
Ensure that the key exchange is done via a separate path from actual message passing.
No.
You cannot do that. Your next hop will be teh same for any path is effectively all situations.
I think you're mixing up authentication with KEX.
That router can MITM the key exchange. It would be sending its own public key in place of the initiators, and doing two key negotiations - one to each party.
Ok- you are mixing up authentication and KEX.
For most things, you have a central trust store or pre-shared fingerprints.
However, there exists methods to do it entirely distributed without a central store.
As I suspect, this is amateur hour right here.
Re: (Score:2)
I think you're mixing up authentication with KEX.
Authentication is a prerequisite for secure key exchange. Without that, you don't know who you're exchanging keys with. Alice and Bob intend to exchange keys with each other, but without some authentication mechanism both could be exchanging keys with Mallory.
Re: (Score:2)
Authentication is a prerequisite for secure key exchange. Without that, you don't know who you're exchanging keys with. Alice and Bob intend to exchange keys with each other, but without some authentication mechanism both could be exchanging keys with Mallory.
Authentication is separate from key exchange.
You certainly want authentication- for sure- but in no way is the key exchange itself vulnerable to a central server. It's the authentication trust that is.
I.e.,
Bob and Alice can securely negotiate a symmetric key between them, in full public view.
What they can't do is be sure it was actually Bob or Alice that they negotiated the key with.
Thus, the authentication problem is separate from KEX, which is not problematic.
I'm amazed we consider anything using a
Re: (Score:2)
However, there exists methods to do it entirely distributed without a central store.
Cite?
I've been doing this stuff for a living for 30 years, and not only have I never seen such a protocol, I can't imagine how it could possibly work. Enlighten me!
Re: (Score:3)
iMessage and Whatsapp, for example, use Key Transparency.
For a distributed CA, the same concept is applied, and it's called Certificate Transparency.
The jist of it is, public logs that are, at the very least, reliably auditable for malicious change attempts- are a solved problem.
Cryptocurrency wouldn't exist otherwise.
Re: (Score:2)
There are several schemes for distributed trust. iMessage and Whatsapp, for example, use Key Transparency.
I stand corrected! I was unaware that they had implemented auditable key transparency. I'll have to look into the details. Google RCS could (and should, and I imagine eventually will) do the same.
Of course, all of these schemes depend on someone actually doing the auditing. They essentially shift the burden from the user to the auditors. But they do make it feasible.
For a distributed CA, the same concept is applied, and it's called Certificate Transparency.
Indeed... I actually worked on some little pieces of the Certificate Transparency log, and some of my immediate teammates were core devel
Re: (Score:2)
Key Exchange protocols absolutely treat middle hops as untrusted.
Sure... but they must do it by having something else they can trust. There are lots of options, but you can't build trust from nothing.
If your 2 devices communicate directly, what happens if a router in the middle is compromised?
Okay, let's start with an example that everyone is familiar with: HTTPS, AKA TLS. We establish secure connections with remote servers all the time, through long sequences of untrusted routers. How does that work?
The way it works is that the server's public key is signed by a trusted authority that the client device trusts. The certificate signed by the CA binds the serv
Re: (Score:2)
Sure... but they must do it by having something else they can trust. There are lots of options, but you can't build trust from nothing.
Key exchange protocols are not concerned with trust.
That's authentication.
Diffie-Hellman is your KEX.
Either a central, or web of trust handles the trust issue- whether or not you're KEXing with who you think you are.
The problem, is indeed authentication.
If you use a central server, then you're not *really* E2EE. Literally anyone can MITM you, because any hop in the pathway can be that "central server".
I had no idea that Signal/Google operated in this fashion.
Whatsapp and iMessage are both ridiculou
Re: (Score:2)
I'm certainly questioning SOMEONE's creds here. Without a step like Signal's ability to do out of band checking, just what is it you think KEX can do about MITM? WITH such a step, the fingerprints don't match and you know there is a man in the middle.
Note, if it turns out you're a Sci-Fi brain in a jar, even out of band isn't really out of band, of course.
Re: (Score:2)
Without a step like Signal's ability to do out of band checking, just what is it you think KEX can do about MITM?
no "ability" to do out of band anything, it's slave to the communications of the device, and its communication pathways.
To answer your question, which I suspect you weren't even qualified to ask given the level of snark, that [wikipedia.org] is how it's done.
Re: (Score:2)
I damn near pulled a muscle laughing!!!
Your link does help, but leaves part of the problem swept under the rug.
Most people would just call voice to verify fingerprints. The most cautious would do it in person. Mail is not out of the question for the cautious.
Like I said, if you're unknowingly a brain in a jar, even those methods won't work, of course. But I consider that risk to be quite small.
Re: (Score:2)
Your link does help, but leaves part of the problem swept under the rug.
Don't know how you figure.
Most people would just call voice to verify fingerprints. The most cautious would do it in person. Mail is not out of the question for the cautious.
This is absurd.
What this means, is that effectively, a small fraction of Signal (and Google Messages RCS, if they really do use "Signal's way of doing it" as claimed above) users are *actually* E2EE with... well, they don't know.
Maybe the person they're talking to. Maybe not.
Using auditable append-only logs, you *know* who you're KEXing with.
Are such logs invulnerable to fuckery? of course not. But they're invulnerable to invisible fuckery. Nobody will ever MITM your ass, as l
Re: (Score:2)
It means *any* country that Signal has their CA stored in can compromise all Signal communications.
I don't get it, sorry. My crypto is rusty, but I did learn how to crack the knapsack algorithm and how triple DES works back in the 90s from the information theory professor at uni, who was on some USA blacklist according to his US peers...
Anyway, if I check the public key of a Signal contact and find it to match and vice versa, then how any server of Signal in any place being taken over by whichever government or other player is irrelevant, they'll never be able to decrypt our conversation, yet you clai
Re: (Score:2)
What keeps me from registering a public key in your name in that log?
Or more to the point, if there is someone out there that I am willing to throw massive resources at spying on, what keeps me from subverting their copy of 'the list' and substituting in keys I control? If they actually know you, they could defeat that by calling you voice.
Meanwhile for signal, consider the fairly small percent of users who actually check keys out of band to be a spot check. If you don't think the sample size is large enoug
Google lies (Score:5, Insightful)
But, we've known for a long time that Google's business model is 'be evil', so, hey.
Re:Google lies (Score:4, Interesting)
Google lies quite shamelessly about a lot of stuff.
Indeed. For example, they have a support page entitled How Google protects your privacy & keeps you in control [google.com].
Re: Google lies (Score:2)
Re: (Score:3, Informative)
Google invades my privacy to get as much data on me as possible. Just because they don't sell my data directly doesn't mean it's protected, the same way a pervert breaking into my house and stealing photos of my kids doesn't protect my kids' privacy just because he keeps the photos to himself.
And you can't stop it. Ever. You can't opt out of the Google surveillance. Ergo, you're not in control.
The entire page is a blatant lie.
Re: Google lies (Score:2)
Re: (Score:2)
If you aren't logged in, they don't associate anything with your account
You can't be this naive...
Google doesn't need any account to know everything there is to know about you better than your own mother. If you create an account with them, you just help them track you a bit easier.
Re: Google lies (Score:2)
Re: (Score:2)
Sorry, not buying what you're selling.
To inject a little bit of personal experience here, my organizations website includes a fuckton of google JS.
I haven't checked what the CORS policy is, but it seems like a stretch to assume they don't exfiltrate some goodies there, without anyone who visits our site knowing it has any connection to google whatsoever, unless they open up the debugging window for their browser.
Re: Google lies (Score:2)
Re: (Score:2)
Its every company and its marketing speak, you have to interpret the statement as the worst possible interpretation and that is the one that most likely applies.
The words are:
conversations are end-to-end encrypted
And technically its true some conversations are end-to-end encrypted, it doesn't specifically say ALL conversations are end-to-end encrypted. Just like "3D ready" sound likes it will just work but actually it means you may need to go out and by something extra to make it work. Or my latest mistake buying with a black friday price guara
Re: (Score:2)
Your statements are at odds with reality.
I wonder where this preponderance of confidence in your own expertise in the subject matter comes from?
Slow news day? (Score:5, Interesting)
This has been known about for years, and has been one of the reasons often cited for why Apple took so long to implement the RCS protocol in IOS - Google didn't want Apple to implement RCS, they wanted Apple to implement the version of RCS which is controlled by Google.
Instead of binding themselves tightly to a "standard" that Google controls, Apple instead very publicly called Google out on their bullshit and said they would implement the RCS standard and work with the standards body to define a true E2EE extension thats not controlled by a proprietary entity. This has been very loudly shouted a lot since Apples decision
Re: Slow news day? (Score:2)
Why hasn't google tried to get it's encryption stuff into the official standard if it's so good?
Re: Slow news day? (Score:5, Insightful)
Currently, if you want to exchange encrypted messages with someone using Googles RCS, you need to use Googles RCS servers.
Having a standardised E2EE implementation means others could host their own servers.
Not standardising it means Google gets to maintain that requirement.
Re: (Score:2)
Re: (Score:3)
And since the ends are controlled by Google (meaning they provide the underlying OS and messsaging software), it's really Google-to-Google encrypted rather than end-to-end encrypted. In other words it's not protected from the world's biggest surveillance system, just some of the others.
RCS encryption uses the Signal protocol. In order for Google to be able to read the messages it would have to not only be involved in the initial key exchange, but in every message afterwards, and since RCS messages pass through carrier servers, not Google's, that would require deep collusion with all of the carriers. That's not impossible, but it's not likely, either.
Compare this with iMessage and WhatsApp, which send key exchanges and messages through the same servers. I don't believe they MITM the con
Re: (Score:2)
They would need do 1 of 2 things:
1: Factor the private keys of the speakers during KEX, or 2: proxy the communications (trick one side into doing a KEX *with them*, and then re-encrypting)
1 isn't feasible.
2 is protected by any reasonable protocol, TLS being the best example.
Re: (Score:2)
Re: (Score:2)
Why would the encryption matter? Google controls the endpoints, no amount of encryption in the world will help you with that.
Sure, if you assume Google will exfiltrate data from the app, which would be really easy to catch. The others could do the same, but the others also have the much less detectable option of doing it server-side.
Re: Slow news day? (Score:4, Interesting)
Not standardising it means Google gets to maintain that requirement.
The protocol is a de facto standard: Signal. Google is working on formally standardizing through GSMA.
Re: (Score:2)
Probably the same reason Apple implemented E2EE in iMessages before getting any body to agree. The GSMA represents the carriers as well as equipment and phone manufacturers. Such a large body does not move quickly. Also within the GSMA are different priorities and goals. The carriers would like nothing more than to sell every bit of your data. The carriers also have to answer to governments about your cellular usage.
This is probably why Google implemented their own E2EE before the GSMA adopted any standards
Re: (Score:3)
Why hasn't google tried to get it's encryption stuff into the official standard if it's so good?
First, it is good. RCS encryption uses the Signal protocol, which is well-regarded and well-studied.
Second, they're working with GSMA to add it to the official RCS standard. It's a slow process.
Re: (Score:2)
It's KEX leaves a little more to be desired, and its authentication is downright miserable.
Don't take my word for it. [sequoia-pgp.org] (Or the blogs- it's full of juicy citations)
Re: (Score:2)
IETF is working on KEYTRANS, but CONIKS and other open source implementations are already in use, and iMessage of course has their own. Whatsapp as well.
If you're not using Key Transparency or some kind of auditable trust store, then your claims of E2EE are bullshit*.
Signal and Google RCS E2EE are broken.
*In that they could become untrue at any time without you knowing.
Re: (Score:2)
If you want to compare the complexity of making a chat program with something like Google maps, the latter is dramatically more difficult. But somehow they managed to do that, without making the former.
Re: (Score:3)
They were fine with hangouts.
I don't know why they threw it out for allo, probably because someone was forced to use some of the technology from the failed Waves?
Re: (Score:2)
They basically just renamed it "Chat," but not without a period of missing features that drove a bunch of the users off.
Re: (Score:2)
Oh right, I forgot about that change.
I stopped using it with all the changes that meant annoyance to keep in touch with friends.
The really screwed up the transition to a single Google account that joined them all, it was a (minor) annoyance each shift and each time fewer people stuck with it while texting became more and more free.
Re: (Score:2)
They've been trying for nearly two decades, and have not succeeded.
That's because they come 2 features short of complete and instead of finishing those two features, they replace it with an entirely new app.
Re: (Score:2)
Exactly! Apple hates proprietary formats and always insists on using open standards.
Re: (Score:2)
open standards like iMessage and Facetime, right?
Re: (Score:2)
I know you are trying to be facetious here, but Apple using its own proprietary standards for iMessage and FaceTime doesn't make them hypocritical - they aren't requiring third parties to bind themselves to an Apple service when communicating between two non-Apple devices.
Thats what Google is wanting handset providers to do with their version of RCS - use Googles servers to get the features Google is trying to shame Apple for not providing.
Re: (Score:2)
I believe I've succeeded.
I don't understand how Google can exert any control of communications happening exclusively between non-Google devices. However, even if that's s
Re: (Score:2)
Google adds their own sauce on top of RCS. It's not very good sauce, but it is sauce.
That sauce only works when you're doing Google Google.
If one side isn't Google though, you can still RCS. It's just not E2EE (to the extent that you can even call Google's that)
iMessage, on the other hand, is E2EE, at least as best as it's possible to be with today's technology.
The ecosystem would indeed be a better place if Apple had just opened u
Google hates SMS (Score:1)
Re: (Score:2)
If they even cared about Google Voice OR RCS they would have implemented RCS with Voice. No plans yet as far as I can tell.
If you cannot do or do not want to, simply lie! (Score:2)
Nobody is going to notice, right? Seriously, this completely inacceptable approach should have pretty bad legal consequences for them.
Gruber? (Score:2)
When your paycheck depends on being an Apple apologist the pretzel bending becomes quite a spectacle.
Google has been putting public pressure on Apple to adopt its Axolotl extension but Apple refuses to keep vendor lock-in for iMessage.
Now that Apple is called out for creating a national security risk the minions are in panic mode.
Somebody reply if there's a hidden obstacle to Apple adopting E2EE RCS that's not talked about. Like patent licenses or whatever.
Google should get all the hell it deserves- when i
Re: (Score:2)
Somebody reply if there's a hidden obstacle to Apple adopting E2EE RCS that's not talked about. Like patent licenses or whatever.
Obstacle, not so much.
The problem is that it's a downgrade from iMessage.
Apple is instead pushing for standardized E2EE via RCS that you can actually call E2EE.
You could argue that Apple could at least implement the shit-tastic MITM-Me-Mommy Google E2EE, and maybe you're right, but then Apple would get the same shit Google gets for its bullshit E2EE claim.
Your Google comms are E2EE***
* As long as you're talking to another Google Messages app, via RCS.
* As long as any government that has jurisdictio
Scroogled was an accurate description (Score:2)