Google: Gmail Client-Side Encryption Now Publicly Available (bleepingcomputer.com) 50
Gmail client-side encryption (CSE) is now generally available for Google Workspace Enterprise Plus, Education Plus, and Education Standard customers. BleepingComputer reports: The feature was first introduced in Gmail on the web as a beta test in December 2022, after being available in Google Drive, Google Docs, Sheets, Slides, Google Meet, and Google Calendar (in beta) since last year. Once enabled, Gmail CSE ensures that any sensitive data sent as part of the email's body and attachments (including inline images) will be unreadable and encrypted before reaching Google's servers. It's also important to note that the email header (including subject, timestamps, and recipients lists) will not be encrypted. "Client-side encryption takes this encryption capability to the next level by ensuring that customers have sole control over their encryption keys -- and thus complete control over all access to their data," Googled explained.
"Starting today, users can send and receive emails or create meeting events with internal colleagues and external parties, knowing that their sensitive data (including inline images and attachments) has been encrypted before it reaches Google servers. As customers retain control over the encryption keys and the identity management service to access those keys, sensitive data is indecipherable to Google and other external entities."
"Starting today, users can send and receive emails or create meeting events with internal colleagues and external parties, knowing that their sensitive data (including inline images and attachments) has been encrypted before it reaches Google servers. As customers retain control over the encryption keys and the identity management service to access those keys, sensitive data is indecipherable to Google and other external entities."
Private key managed by Google controlled code. (Score:5, Insightful)
Like the other offerings of the same ilk (Drive, Docs, Calendar), this is not as secure as it makes out to be. The private key is managed by Google controlled code and thus within their reach, if they were compelled to decrypt.
Re: (Score:3)
Re: (Score:1)
Can either implement your own key service, or use one of the (separate) providers:
https://support.google.com/a/a... [google.com]
Re: (Score:2)
I too am skeptical, unless it is kept to paying customers only it would break their advertising model in the long run, since it hides the content of the mail from targeted adverts. If everyone in the world went PGP encryption then there would be no way to target adverts outside of the subject line.
Re:Private key managed by Google controlled code. (Score:5, Insightful)
False. The private key is managed by code under full control of Google. That this code executes on the device and not on Google's servers means they may have to push an update or activate hidden functionality to access the key or leak the key using some form of steganography, but that is it. Believing this set-up somehow protects the user against Google is terminally naive. Obviously (and as you just demonstrated) there are a ton of naive people out there with no clue how things actually work, but that does not prevent the rest of us who have that clue from seeing a thing for what it is.
Re: (Score:3)
But that is true of all end-to-end encryption. If you don't trust the entire client stack down to the chips themselves then the key can be ex-filtrated, and you are trusting someone, usually quite a few someones.
Google could open source and give some foundation the client source code to maintain, and you could audit it yourself.
And you'd still be trusting Google not to exfiltrate your keys on an android, trusting apple on an iphone, etc, etc.
Also, legally speaking, there is a chasm of difference between 'wh
Re:Private key managed by Google controlled code. (Score:4, Informative)
But that is true of all end-to-end encryption.
Ah, no? Google can do a few things in this set-up because they own _everything_ about it. In the regular case (say, PGP on a computer) a number of parties must be compelled and they all must all cooperate and keep silent. In the Google case, individual, targeted attacks are easy and cheap as hell and nobody except Google is involved.
Re: (Score:2)
"Google can do a few things in this set-up because they own _everything_ about it."
The things google can do vs say a microsoft or apple to their users to get at your gmail credentials/keys isn't really that much more limited.
" In the regular case (say, PGP on a computer)"
Presumably on linux right? Because otherwise you are trusting apple or microsoft not to exfiltrate your key. And pgp on linux is a rounding error in the email world, so i'm not sure it's reasonable to call it the 'regular case'.
Re: (Score:3)
Re: (Score:1)
To use Google Workspace Client-side encryption (CSE), you first need to set up one or more external key services. You can do either of the following:
Re: (Score:2)
For these kinds of systems, most of the time the EULA explicitly tells you the keys are stored on the cloud. Why anybody thinks a product pitched as "client-side" is actually under user control is beyond me.
Quick question (Score:2)
Is this PGP with more or less steps?
Re: (Score:2)
Well, it's more or less PGP.
Re:Quick question (Score:5, Insightful)
It is PGP without the security. At least if the attacker is Google itself.
Real-world use cases or scenarios? (Score:2)
Could someone describe how or why would your organization use this?
I cannot figure out a real use case. My companies have used Google as identity provider, email / office / comms tool and so on. In all those cases, you will and must trust Google fully. You will list it as your data sub-processor, you will trust it with tour passwords (in Chrome storage or wherever) and 2FA and so on.
Having an encryption layer on top of this... changes nothing.
I understand the tech, but I don't understand the need.
Does anyon
Re: (Score:3, Interesting)
Re: (Score:3)
Re: (Score:1)
Encryption server (or provider) only provides the key for use in decrypting the contents of the email in the browser. It cannot see the contents of the email.
Re: (Score:3)
Encryption server (or provider) only provides the key for use in decrypting the contents of the email in the browser. It cannot see the contents of the email.
Though correct that the external encryption key service only provides the key, they also clearly state in their FAQ:
How is CSE different from end-to-end (e2e) encryption?
With client-side encryption (CSE), encryption and decryption also always occur on the source and destination devices, which in this case are the clients' browsers. However, with CSE, clients use encryption keys that are generated and stored in a cloud-based key management service, so you can control the keys and who has access to them. For
Re: (Score:3)
Re:Real-world use cases or scenarios? (Score:5, Insightful)
And Google is entirely free to have backdoors in their software, leak keys, etc. As long as they control the gmail client, Google has access if they want to. Believing anything else is just utterly naive.
Re:Real-world use cases or scenarios? (Score:4)
Don't let perfect be the enemy of good. Most email is unencrypted and every attempt to get people to use encryption has failed.
This gives organizations a very easy and transparent way to enable encryption for their staff. While yes in theory Google might have backdoored it, risking massive reputational damage and probably some criminal charges too, even if they have it's still vastly better than the alternative: nothing.
Re:Real-world use cases or scenarios? (Score:4, Funny)
Don't let perfect be the enemy of good.
Don't let stupid bullshit be the enemy of good, either. Getting your encryption software from a member of PRISM is like buying your condoms from the Vatican.
Re: (Score:2)
Don't let perfect be the enemy of good.
Don't let stupid bullshit be the enemy of good, either. Getting your encryption software from a member of PRISM is like buying your condoms from the Vatican.
Actually, buying condoms from Companies with (partial or full) Vatican ownership is probably safe, as "backdoors" in these would become publicly known without a year or so.
Re: (Score:2)
I searched out of curiosity, it turns out the Vatican pharmacy does not sell contraceptives https://en.wikipedia.org/wiki/... [wikipedia.org] They would not sell backdoored condoms, because in their view it's the intent of using condoms that is a sin, even is the execution is ineffective. The intent of Vatican is that there is no sin, not to increase the number of children at all costs. The same way I intended to kill the President (or the Pope) and the police knew, they would arrest me as soon as they could, not provide m
Re: (Score:1)
Okay, you don't trust it. What is your alternative?
Forget GPG, tried that, doesn't work. Forget Signal, you need email for documentation/archival.
What are you going to use instead?
Re: (Score:2)
Forget GPG, tried that, doesn't work.
Yes, it does work. There are multiple browser addons to implement gpg with gmail for example. I used to install them but nobody else was using encryption so I gave up. If you can't figure out how to use GPG with Gmail, then I really, really don't know what else to say to you.
Re: (Score:2)
Nobody else uses them because they are unsupported at best. Besides, you are just trusting some random extension maker with access to your Gmail account. You could try to look at the source, but most IT departments are not qualified to safe if it is safe or not.
If there was another solution then businesses would be using it. Google is offering them a way to tick that box on their security and compliance audit, and realistically those businesses are probably more at risk from their own employees than from so
Re: (Score:2)
Re: (Score:3)
The one thing that is worse than bad security is fake "good" security, because then people start to rely on it and become _less_ secure.
You are wrong, sorry.
Re: Real-world use cases or scenarios? (Score:1)
Re: (Score:3)
The "use case" is often called "feel-good security" which is not a form of security, fake-security intended to make those without a clue feel good about themselves. Works really well on a lot of people, because the vast majority of the human race has no clue as to how things actually work. Obviously the primary attacker here is Google itself and they will have no trouble obtaining your key or messages if they want to. It does not even need to be as blatant as grabbing your secret key. It would be perfectly
Re: (Score:2)
Could someone describe how or why would your organization use this?
It's for people smart enough to know they need encryption, but too stupid to get encryption from someone other than the people running the server. IoW, it's for nobody.
When Is It Coming To Regular Gmail? (Score:4, Interesting)
Just curious.
Assume a sperical user of uniform density (Score:1)
At least some people can be taught to save attachment, right click on it, select decrypt, then treat the result like a normal archive. Yet we like to assume nobody can. So encryption must be cookie-cutter and "user-friendly". I don't think that's sustainable.
It also doesn't mesh well with throwing highfalutin' crap in there that only a crypt-utopia-nerd (pgp's web of trust) or a bureaucrat (the hassle with certificates) would love. I don't think trying to paper over all that with yet another layer of in-th
Unencrypted headers == Discovery & FISA motion (Score:2)
By not encrypting the email headers, you are making all of those communications vulnerable to discovery motions and FISA warrants against Google. If not only yourself, but anyone you have ever emailed is scooped up in a FISA warrant, all of your communications can become part of the evidence.
Re: (Score:2)
By not encrypting the email headers, you are making all of those communications vulnerable to discovery motions and FISA warrants against Google.
The whole purpose of this feature... well, it's to sucker the suckers, really. But the idea is that the content of the mail is encrypted in a way that google can't read it. If you encrypt the headers as well, they cannot deliver the mail. Conversely, even if the headers were encrypted somehow, in a way that google could read them, guess what? They have to decrypt them to read them, and they are a member of PRISM, so the only safe assumption is that they will forward the headers on to the DHS anyway.
Maybe le
Re: (Score:2)
Er.. I know how email works, thanks.
What I am trying to highlight is there is no way to securely send email from a personal or work account like this. It is a false flag, and I don't want people to fall for this.
Re: (Score:2)
If the mail is expected to pass through even one server outside of your control, there is no header security. That's why nobody expects there to be any.
Re: (Score:2)
Exactly - so don't do it. Use an anonymous account with something like Protonmail or use a totally different communications mechanism.
Email should never be relied on for secure communications. It is insecure by design, and can not be made secure.
Re: (Score:2)
OK, but you cannot solve this problem with any system where the message has to go to another system. At some point, some server outside of your control has to decode the headers so they can be used for routing. You can already choose to put nothing meaningful into any of the headers except the destination*, so that really doesn't differentiate email from anything else.
* And of course you also have to use a valid from domain these days, if you expect your mail to be delivered, so anti-spam measures have made
Re: (Score:2)
The point is, if I send email from Protonmail, it can not be tied to me due to how Protonmail works. So even if it gets scooped up in a FISA warrant or other discovery, it does not matter.
If your Gmail gets scooped up in a FISA warrant or discover process, it can certainly be tied to you - which now brings *ALL OTHER ACTIVITY* into scope as well.
Re: (Score:3)
The point is, if I send email from Protonmail, it can not be tied to me due to how Protonmail works.
hahaha no [privacyaffairs.com]
Re: (Score:2)
If you do something on a computer, it CAN be tied to you. It's just a matter of getting the right access and logs. It may be extremely difficult and MAY not be possible at some point in time. But, it's never a good idea to think there is some bulletproof system that allows you to send messages 100% safely without being traceable.
My opinion (Score:1)