Gmail client-side encryption: A deep dive

In February, we (CSE) capabilities to include Gmail and Calendar in addition to .

CSE in Gmail was designed to provide commercial and public sector organizations an additional layer of confidentiality and data integrity protection beyond providing software implementations of the KACLS API that can be used by our customers. 

When sending an email, the Gmail client generates a MIME message, encrypts the message with a random Data Encryption Key (DEK) then uses the recipients' public keys to encrypt the DEK, calls KACLS (with the user authenticated by customer's IdP and authorized by Google) to digitally sign content and finally sends the authenticated and encrypted S/MIME message, which contains both the encrypted email and the encrypted DEK, to Google servers for delivery to the recipients. Below is an animated screenshot showing the user interface of Gmail when using CSE.

What’s next for Client-side encryption and why it’s important 

CSE in Gmail uses S/MIME to encrypt and digitally sign emails using public keys supplied by customers, which add an additional level of confidentiality and integrity to emails. This is done with extensive security controls to protect user data confidentiality, but also transparently integrated in Gmail UI to delight our users. However our work is not done, and we are actively partnering with where we provided insight into the challenges and the practical strategies to provide advanced capabilities, such as AI-driven phishing protection for CSE.