CLIENT-SIDE ENCRYPTION Google unveils end-to-end messages for Gmail. Only thing is: Its not true E2EE. Yes, encryption/decryption occurs on end-user devices, but there's a catch. Dan Goodin Apr 3, 2025 5:16 pm | 10 Credit: Getty Images Credit: Getty Images Story textSizeSmallStandardLargeWidth *StandardWideLinksStandardOrange* Subscribers only Learn moreWhen Google announced Tuesday that end-to-end encrypted messages were coming to Gmail for business users, some people balked, noting it wasnt true E2EE as the term is known in privacy and security circles. Others wondered precisely how it works under the hood. Heres a description of what the new service does and doesnt do, as well as some of the basic security that underpins it.When Google uses the term E2EE in this context, it means that an email is encrypted inside Chrome, Firefox, or just about any other browser the sender chooses. As the message makes its way to its destination, it remains encrypted and cant be decrypted until it arrives at its final destination, when its decrypted in the recipient's browser.Giving S/MIME the heave-hoThe chief selling point of this new service is that it allows government agencies and the businesses that work with them to comply with a raft of security and privacy regulations and at the same time eliminates the massive headaches that have traditionally plagued anyone deploying such regulation-compliant email systems. Up to now, the most common means has been S/MIME, a standard so complex and painful that only the bravest and most well-resourced organizations tend to implement it.S/MIME requires each sender and receiver to have an X.509 certificate thats been issued by a certificate authority. Obtaining, distributing, and managing these certificates in a secure manner takes time, money, and coordination. That means that if Bob and Alice have never worked together before and an urgent or unexpected need arises for him to send Alice an encrypted message promptly, theyre out of luck until an admin applies for a certificate and sees that its installed on Alices machineso much for flexibility and agility.Google says that E2EE Gmail abstracts away this complexity. Instead, Bob drafts an email to Alice, clicks a button that turns on the feature, and hits send. Bobs browser encrypts the message, and sends it to Alice. The message decrypts only after it arrives in Alices browser and she authenticates herself.To make this happen, Bobs organization deploys what Google says is a lightweight key server, known as a KACL, short for a key access control list. This server, which can be hosted on premises or most cloud services, is where keys are generated and stored. When Bob sends an encrypted message, his browser connects to the key server and obtains an ephemeral symmetric encryption key. Bobs browser encrypts the message and sends it to Alice, along with a reference key. Alices browser uses the reference key to download the symmetric key from the KACL and decrypts the message. The key is then deleted.To prevent Mallory or another adversary-in-the-middle from obtaining the key, Alice must first authenticate herself through Okta, Ping, or whatever other identity provider, or IDP, Bobs organization uses. If this is the first time Alice has received a message from Bobs organization, she will first have to prove to the IDP that she has control of her email address. If Alice plans to receive encrypted emails from Bobs organization in the future, Alice sets up an account that can be used going forward.Bobs organization can add an additional layer of protection by requiring Alice to already have an account on the IDP and authenticate herself through it.The idea is that no matter what, at no time and in no way does Gmail ever have the real key. Never, Julien Duplant, a Google Workspace product manager, told Ars. And we never have the decrypted content. Its only happening on that users device.Now, as to whether this constitutes true E2EE, it likely doesnt, at least under stricter definitions that are commonly used. To purists, E2EE means that only the sender and the recipient have the means necessary to encrypt and decrypt the message. Thats not the case here, since the people inside Bobs organization who deployed and manage the KACL have true custody of the key.In other words, the actual encryption and decryption process occurs on the end-user devices, not on the organizations server or anywhere else in between. Thats the part that Google says is E2EE. The keys, however, are managed by Bobs organization. Admins with full access can snoop on the communications at any time.The mechanism making all of this possible is what Google calls CSE, short for client-side encryption. It provides a simple programming interface that streamlines the process. Until now, CSE worked only with S/MIME. Whats new here is a mechanism for securely sharing a symmetric key between Bobs organization and Alice or anyone else Bob wants to email.The new feature is of potential value to organizations that must comply with onerous regulations mandating end-to-end encryption. It most definitely isnt suitable for consumers or anyone who wants sole control over the messages they send. Privacy advocates, take note.Dan GoodinSenior Security EditorDan GoodinSenior Security Editor Dan Goodin is Senior Security Editor at Ars Technica, where he oversees coverage of malware, computer espionage, botnets, hardware hacking, encryption, and passwords. In his spare time, he enjoys gardening, cooking, and following the independent music scene. Dan is based in San Francisco. Follow him at here on Mastodon and here on Bluesky. Contact him on Signal at DanArs.82. 10 Comments