> My assumption is that Google has keys to everything in its kingdom
If that were true, then their claims to support E2E encrypted backups are simply false, and they would have been subject to warrants to unlock backups, just like Apple had been until they implemented their "Advanced Data Protection" in 2022.
Wouldn't there have been be some evidence of that in the past 7 years, either through security research, or through convictions that hinged on information that was gotten from a supposedly E2E-protected backup?
It is possible to set up end to end encryption where two different keys unlock your data. Your key, and a government key. I assume google does this.
1. encrypt data with special key
2. encrypt special key with users key, and
3. encrypt special key with government key
Anyone with the special key can read the data.the user key or the government key can be used to get special key.
This two step process can be done for good or bad purposes. A user can have their key on their device, and a second backup key could be in a usb stick locked in a safe, so if you loose your phone you can get your data back using the second key.
"…two different keys…. Your key, and a government key. I assume google does this."
With the present state of politics—lack of both government and corporate ethics, deception, availability of much fake news, etc.—there's no guarantee that you could be certain of the accuracy of any information about this no matter what its source or apparent authenticity.
I'd thus suggest it'd be foolhardy to assume that total privacy is assured on any of these services.
BTW, I don't have need of these E2E services and don't use them, nor would I ever use them intentionally to send encrypted information. That said, occasionally, I'll send a PDF or such to say a relative containing some personal info and to minimize it being skimmed off by all-and-sundry—data brokers, etc. I'll encrypt it, but I always do so on the assumption that government can read it (that's if it's bothered to do so).
Only fools ought to think otherwise. Clearly, those in the know who actually require unbreakable encryption use other systems that are able to be better audited. If I were ever in their position, then I'd still be suspicious and only out of sheer necessity/desperation would I send an absolute minimum of information.
Yes. There is no ability to know one way or the other if Google, and similar services retain a secondary way to access decryption key. In light of this the only option is to _assume_ they have the capability.
Given the carefully crafted way companies describe their encryption services, it seems more likely than not they have master keys of some sort.
That would definitely be a safe assumption, that Google can look into anything they own or is on what they own. It's not like they are strong privacy advocates or don't already cooperate with any state apparatus they see as profitable or to their benefit.
> …there's no guarantee that you could be certain of the accuracy of any information about this no matter what its source or apparent authenticity.
In any case like this, the only thing you could truly trust would be the source code and even then you’d have to be on the lookout for backdoors, which would definitely be beyond my own capability to spot.
In other words, the best bet is to probably only use open source solutions that have been audited and have a good track record, wherever available. Not that there are that many options when it comes to mobile OSes, although at least there are some for file storage and encryption.
Obviously, that's the ideal course of action but I'd reckon that in practice those who would have both a good understanding of the code as well as the intricacies/strengths of encryption algorithms and who also have need to send encrypted messages is vanishing small—except perhaps for some well-known government agencies.
Just because something you do today is legal and not a cause for scrutiny does not mean the same will be true tomorrow.
We have seen this many times throughout history, where people like academics, researchers, teachers, people of particular faith, etc are targeted and each of them has some sort of “evidence” produced as to some sort of crime they have committed either in the present or past to justify their arrest.
The group who needs it today may be small, but having it on and secure by default for all is a far better protection than any justification that the current need is small.
E2EE means only your intended recipients can access the plaintext. Unless you intend to give the government access to your plaintext, what you described isn’t E2EE.
Is that google's definition or your definition? not being rude, but its pretty easy to get tricky about this.
Since you are sending the data to google, isn't google an intended recipient? Google has to comply with a variety of laws, and it is likely that they are doing the best they can under the legal constraints. The law just doesn't allow systems like this.
history already proved you wrong. companies offering backdoor to abusive law enforcement are never sued.
they also employ things like exempt cases. for example, Whatsapp advertise E2E... but connect for the first time with a business account to see all the caveats that in plain text just means "meta will sign your messages from this point on with a dozen keys"
You are extremely naive if you think a company the size of Google or Microsoft or Apple will face any serious consequence from lying about E2EE actually being open to various governments.
They have lawyers aplenty, governments would file amicus briefs "explaining" E2EE and so on. Worse case they'll settle for a pittance.
So all you’ve got is hypotheticals that coincidentally confirm your biases? These are giant companies. Show me where a civil suit for lying about a product’s security was defended by this kind of claim.
Oh thanks. I've never done that before. I'll try that, it'll be very interesting to see those disclaimers.
I guess for consumer use all that stuff is hidden in the T&C legalese which is unreadable for normal people. I know the EU was trying to enforce that there must be a TL;DR in normal language but I haven't seen much effect of that yet.
> E2EE means only your intended recipients can access the plaintext.
No, it does not. It means that only endpoints - not intermediaries - handle plaintext. It says nothing about who those endpoints are or who the software is working for.
No, it is not. This is precisely why we have the term E2EE. An escrow agent having your keys but pinky promising not to touch them is indistinguishable from the escrow agent simply having your plaintext.
Unless you’re fine with the escrow agent and anybody they’re willing to share the keys with being a member of your group chat, in which case my original point still stands.
Edit: I think you might be confusing your personal intention (ie I wanted this to be private but didn't realize the service provider retained a copy of the keys) with the intention of the protocol (ie what the system is designed to send where). Key escrow is "by design" whereas E2EE protects against both system intrusions (very much not by design) as well as things like bugs in server software or human error when handling data.
> is indistinguishable
Technically correct (with respect to the escrow agent specifically) but rather misleading. With E2EE intermediary nodes serving or routing a request do not have access to it. This protects you against compromise of those systems. That's the point of E2EE - only authorized endpoints have access.
The entire point of key escrow is that the escrow agent is authorized. So, yes, the escrow agent has access to your stuff. That doesn't somehow make it "not E2EE". The point of E2EE is that you don't have to trust the infra. You do of course have to trust anyone who has the keys, which includes any escrow agents.
If we used the definition "only your intended recipients can access the plaintext" ... well let's be clear here, an escrow agent is very much an "intended recipient", so there's no issue.
But lets extrapolate that definition. That would make E2EE a property of the session rather than the implementation. For example if my device is compromised and my (E2EE) chat history leaks suddenly that history would no longer be considered E2EE ... even though the software and protocol haven't changed. It's utterly nonsensical.
> I think you might be confusing your personal intention with the intention of the protocol
So what would be the name for a mechanism where escrow is deliberately not a part of the design and nobody aside from the sender and recipient can access the plaintext data, no 3rd parties whatsoever, as long as those two participants aren’t compromised.
I’m not disagreeing with you but I’ve heard people talk about E2EE while actually thinking it’s more like the above. There is probably a term for truly private communication but I’m sleepy and it eludes me.
The literal answer to your question would be "E2EE without key escrow" I guess. Or E2EE between just me and this single party.
However I don't think that's so much a technical mechanism as it is a statement of preference or understanding about who you intend to have access to something.
To that end, you'll need to define "intended recipient" pretty carefully. After all, your intended recipient could take a screenshot and share it. Or there could be someone in a group chat who isn't participating and you forgot was there. Etc.
> There is probably a term for truly private communication
I'd argue that E2EE is "truly private" between the intended recipients, and that understanding who exactly those are is entirely the responsibility of the user.
Of course I recognize that we're talking past each other at that point. Your concern seems to be users not realizing an escrow agent is present. To the extent they might have been deceived about the implementation I'd point out that "snuck in an escrow agent" is just the tip of the security iceberg. They could also have been deceived about the implementation itself. And even if they weren't deceived initially, a binary or web app could be intentionally updated with a malicious version. Does it count as "truly private" if you didn't compile it yourself?
> Of course I recognize that we're talking past each other at that point. Your concern seems to be users not realizing an escrow agent is present. To the extent they might have been deceived about the implementation I'd point out that "snuck in an escrow agent" is just the tip of the security iceberg. They could also have been deceived about the implementation itself. And even if they weren't deceived initially, a binary or web app could be intentionally updated with a malicious version. Does it count as "truly private" if you didn't compile it yourself?
All of these are good points, thanks for taking the time to respond! I think that to a certain degree this means that, for the average layperson and someone with more skills and knowledge, there are still a bunch of challenges and attack vectors to contend with.
It probably involves more of something in the category of OpenPGP (or just Signal, I guess) where you yourselves are in control of the keys, and less of counting on various web apps to do right by the users. That said, E2EE with escrow is still helpful against certain risks and is a net positive, even if I've seen a lot of that misunderstanding about what it actually does.
No problem! The more people conscious of this stuff the better off we all are in the long run.
Anything that you can either audit or compile yourself is generally a good bet. You might add Matrix, XMPP with OMEMO, Briar, and Cwtch to your list.
Proprietary stuff isn't an entirely bad deal though. If you assume they aren't blatantly fraudulent then presumably your data is better protected than it would have been without even an attempt at E2EE.
Same for key escrow schemes. Even if the agent was literally the NSA you'd still most likely be better off than the much more vulnerable alternative. The fewer entities with access and the more deliberate that access is the better.
Well, WhatsApp backups claim they are E2E encrypted, but there’s a flow that uses their HSM for the encryption key, which still feels like some escrow system.
True but you can choose to store the key completely yourself. That fixes a big backdoor that's been around for ages.
The biggest problem remaining to me is that you don't chat alone. You're always chatting with one or more people. Right now there's no way of knowing how they handle their backups and thus the complete history of your chats with them.
It's the same thing as trying to avoid big tech reading your emails by setting up your own mailserver. Technically you can do it but in practice it's pointless because 95% of your emails go to users of Microsoft or Google anyway these days.
Those would be end-to-end encrypted x how many recipients you intend for. Very different from (end-to-end-encrypted x how many recipients you intend for) + an arbitrary amount of recipients you don't intend for.
Presumably there are a finite number of escrow agents who are known to you. Worrying that they will pass your messages along to others is the same as worrying that the people you're chatting with do the same. It's always on you to assess the trustworthiness of the other parties; key escrow is no exception to that.
To be clear I'm not a fan of large scale key escrow schemes and am not going to willingly use one outside of a corporate setting. But lets have accurate use of terminology while discussing these things.
Surely a company with auditing requirements running their own key escrow would still be considered E2EE? If not E2EE then what would you suppose to call that and where would you draw the line?
> Worrying that they will pass your messages along to others is the same as worrying that the people you're chatting with do the same.
This makes absolutely _no sense_. If I do not trust my end user to not propagate the message I send them, then I will not send them that message. There is no need for a third party here to make that mistake. It _is_ that black and white. Adding another end user is compromising your promise on the secure communication you established. There is no workaround to that.
Similarly, if you do not trust a particular escrow agent then do not use that escrow agent.
I can imagine a likely objection. "But I'm forced to use this particular agent by [ tech company | employer | government ]!" I don't see how that's any different from needing to communicate with a particular person. If I need to communicate with someone and I don't trust them not to share things then I will (must!) compose my correspondence accordingly.
If the government is forcing this on you, well, what is the alternative? Is point to point encryption somehow better in that scenario? Either way they're getting copies of everything you write assuming that the service you're using abides by the law. With key escrow that snooping is more explicit and there are fewer unknowns for the end user.
Manufacturers have lied about E2EE since the beginning. Some claim that having the key doesn't change that it's e2ee. Others claim that using https = e2ee, because it's encrypted from one end to the other, you see? (A recent example is Anker Eufy)
The point is that the dictionary definition of E2EE really doesn't matter. Being pedantic about it doesn't help. The only thing that matters is that the vendor describes what they call E2EE.
Yes, but going by that, most messaging services advertised as "E2EE" are already not E2EE by default. You trust them to give you the correct public keys for peer users, unless you verify your peers in-person. Some like iMessage didn't even have that feature until recently.
To call it lying is just arguing about the meanings of words. This is literally what lawyers are paid to do. The data payload can be called end to end encrypted. You can easily say to the user that "your emails are encrypted from end to end, they are encrypted before it leaves your computer and decrypted on the receivers computer" without talking about how your key server works.
Systems that incorporate a method to allow unlocking using multiple keys don't usually advertise the fact that this is happening. People may even be legally obligated to not tell you.
“End-to-end encryption (E2EE) is a method of implementing a secure communication system where only communicating users can participate. No one else, including the system provider, telecom providers, Internet providers or malicious actors, can access the cryptographic keys needed to read or send messages.”
So if you send another set of keys to someone else, it’s obviously not E2E.
I agree completely that it is wrong in spirit. But wikipedia's text is a definition, not the only existing one. And for practical use even the most obvious definitions have legal caveats.
For example, asking for 10 gallons of soda at a restaurant advertising unlimited refills will not fly, even though virtually everyone will agree on the definition of the term "unlimited". My 2c.
I expect this is what they are all doing tbh, although isnt google open source? should be checkable, if the binaries the distribute match the source... oh...
"a special key" afaik is where instead of using 2 large primes for a public key, it uses 1 large prime and the other is a factor of 2 biggish primes, where 1 of the biggish is known, knowing one of the factors lets you factor any public key with a not insignificant but still more compute than most people have access to.
UK has also invested in some serious compute that would appear dedicated to exactly this task.
basically if you dont have full control over the key generation mechansim and enc/dec mechansim it is relatively trivial for states to backdoor anything they want.
A trivial method for circumventing code review is to simply push a targeted update of the firmware to devices subject to a government search order.
There are no practical end-user protections against this vector.
PS: I strongly suspect that at least a few public package distribution services are run by security agencies to enable this kind of attack. They can distribute clean packages 99.999% of the time, except for a handful of targeted servers in countries being spied upon. A good example is Chocolatey, which popped up out of nowhere, had no visible source of funding, no mention of their ownership structure anywhere, and was incorporated along with hundreds of other companies in a small building in the middle of nowhere. It just screams of being a CIA front, but obviously that's hard to prove.
Chocolatey assuredly did not "pop up out of nowhere" - it was a labour of love from Rob Reynolds to make Windows even barely usable. It likely existed for years before you ever heard of it.
> had no visible source of funding
Rob was employed by Puppet Labs to develop it until he started the commercial entity which now backs it.
> a small building in the middle of nowhere.
As I recall, Rob lives in Topeka, Kansas. It follows that his business would be incorporated there, no?
There was no evidence of any of this on the website until recently (maybe 2 or 3 years ago?), and I did look at every page on there. Similarly, I searched on Google for a while and raised the question in more than a few forums. I dug through the business registration records, etc... and found none of the above.
Look at it from the perspective of a paranoid sysadmin half way around the world raising a quizzical eyebrow when random Reddit posts mention how convenient it is, but it's distributing binaries to servers with absolutely no obvious links back to any organisations, people, or even a legitimate looking business building.
The end user protection is to sign updates and publish the fingerprints. It should not be possible for one device to get a different binary than everyone else.
How exactly do you plan on implementing this as an end user?
Even if you somehow manage to ensure 100% consistency with other users for updates you manually “pull” from the vendor, the vendor could simply have your device automatically reach out and update itself with a stealth update.
Or everyone can get the same exact binary, but it has a hash code check on it that activates the evil bits only on your device.
> They were curious to learn which open source libraries are integrated to the Telegram app. You know, on the client side," Durov said. "And they were trying to persuade him to use certain open source tools that he would then integrate into the Telegram code
Is the source code for every binary blob present on an Android device available for inspection, and is the code running on every Android device verifiable as having been built from that source?
> or through convictions
If they wanted to use this evidence for a normal criminal case, they would just do parallel construction.
Would it be possible that they feel that the revelation of this backdoor would be too big of a loss so that any of these theoretical cases of the past 7 years have used parallel construction to avoid revealing the encrypted data was viewed?
It's worth noting that what the security services don't have access to is as secret as what they do have access to. According to the late Ross Anderson, for many years the police were unable to trace calls (or was it internet access?) on one of the major UK mobile networks, because it had been designed without that and in such a way that it was hard to retrofit. This was considered highly confidential, lest all the drug dealers etc switch to that network.
> Wouldn't there have been be some evidence of that in the past 7 years, either through security research, or through convictions that hinged on information that was gotten from a supposedly E2E-protected backup?
I wouldn't count on it. The main way we'd know about it would be a whistleblower at Google, and whistleblowers are extremely rare. Evidence and court records that might expose a secret backdoor or that the government was getting data from Google that was supposed to be private could easily be kept hidden from the public by sealing it all away for "national security reasons" or by obscuring it though parallel construction.
There were a lot of people working for the NSA besides snowden, but none of them blew the whistle even though some of the programs he exposed had been around for 12 years. There were a whole lot of people working at AT&T but employees weren't lining up to tell us about Room 641A (https://en.wikipedia.org/wiki/Room_641A) before Mark Klein. How did everyone else manage to be kept quiet? The details about MKUltra and the Manhattan Project were successfully kept a secret for decades before eventually being declassified.
It'd be a huge mistake to look at the instances where somebody did come forward and spill a secret and assume that it means secrets aren't possible to keep or that there are no secrets being kept right now. It's may not be easy to keep a secret, but governments and corporations are extremely well practiced and have many documented successes.
You have a point, but a major reason that the examples you cited above were kept secret was because knowledge about them was compartmentalized. As knowledge leaks, so does the possibility of whistleblowers. It’s an unstable equilibrium. My argument (which admittedly is based on an anecdata about how undisciplined large tech corporations are) is that it’s uniquely hard to keep secrets in modern tech companies because by design, knowledge is not compartmentalized. Modern large tech companies have replaced fiefdoms of knowledge with fiefdoms of operational expertise, if that makes sense.
Anyway, there have been hundreds, perhaps thousands of whistleblowers in the past and the examples you picked I think are representative of the upper bound, rather than the lower bound of the secret keeping capacity of organizations.
They might have keys to everything in their kingdom, but only if you look through the right len$$
--
as one who helped build the total awareness apparatus, I dont care about my privacy, only as a defeatist.
The only weapon again is trancperency of the Entanglements (recall that term, about AI entanglements?) -- What is unclear, is, WRT to these current revealings /confirmations(DOGE, etc) -- Are these institutions being untangled and removed, or squeezed out of their territory?
They are so used to bend reality that could easily call it e2e encryption even if the key was generated by Google or had a skew that made it vulnerable with some extra knowledge that they have or will have in the next sync.
I don't know the particulars, but in general, silence around a massive tech company on warrants does not mean "they said no and the feds decided to leave them alone"
I doubt it. Much to my annoyance they moved Google Maps Timeline from their database to an encrypted copy on my phone specifically so if law enforcement asks for the records of where you were at a given time and place they can say dunno, can't tell. If they had the keys it would wreck their legal strategy not to get hassled every time law enforcement are trying to track someone.
The linked article makes a lot of assumptions about the "Massive Digital Data Systems Program". It seems this program existed. For example, here is a 1996 paper [1] about research funded by the "Massive Digital Data Systems (MDDS) Program, through the Department of Defense."
But it's not clear that funding for early research into data warehousing (back when a terabyte was a lot of data) has anything to do with whether or not Google uses end-to-end encryption? Lots of research got funded through the Department of Defense.
Without having relevant evidence, this is just "let's assume X is true, therefore X is true."
Google didn't announce that they could no longer process geofence warrants because they no longer stored a copy of user location data on their servers until last October.
How much good does an encrypted device backup do when harvesting user data and storing it on your servers (to make ad sales more profitable) is your entire business model?
This would mean no independent security researcher has ever taken a look at Google Drive's E2EE on Android. Or those that did missed the part where the key is uploaded.
It's possible to decrypt this network traffic and see if the key is sent. It may be obfuscated though.
[1] https://qz.com/1145669/googles-true-origin-partly-lies-in-ci...