{"id":2596,"date":"2025-04-01T23:33:38","date_gmt":"2025-04-01T23:33:38","guid":{"rendered":"https:\/\/cybersecurityinfocus.com\/?p=2596"},"modified":"2025-04-01T23:33:38","modified_gmt":"2025-04-01T23:33:38","slug":"google-adds-end-to-end-email-encryption-to-gmail","status":"publish","type":"post","link":"https:\/\/cybersecurityinfocus.com\/?p=2596","title":{"rendered":"Google adds end-to-end email encryption to Gmail"},"content":{"rendered":"
\n
\n
\n
\n
<\/div>\n

Google has introduced a new end-to-end encryption (E2EE) feature in Gmail, enabling organizations to send encrypted emails that even Google cannot read to other Gmail users. Later this year, the feature will be expanded to allow the sending of encrypted emails to any email users, including those from other providers.<\/p>\n

E2EE differs from encrypting email communication in transit between email servers, which is already achieved with TLS<\/a> (transport layer security), or at rest when stored in Google\u2019s data centers. E2EE allows users to encrypt sent messages in a way that only the intended recipients can decrypt and read them.<\/p>\n

How end-to-end encryption works<\/h2>\n

E2EE for email is typically achieved with Secure\/Multipurpose Internet Mail Extensions (S\/MIME), a public protocol and standard that uses public-key cryptography to sign and encrypt messages. However, implementing S\/MIME is not straightforward, usually involving digital certificate acquisition and management for every user. Additionally, it only works with recipients who also have S\/MIME configured.<\/p>\n

There are proprietary solutions for end-to-end encryption that involve deploying additional software, browser extensions, or web portals. Organizations in certain regulated industry sectors, including government agencies, typically go through the trouble of setting up such E2EE solutions for sensitive emails, but most other organizations avoid them due to usability issues.<\/p>\n

\u201cThese gaps and challenges have created real friction for both IT teams and users for decades,\u201d Johney Burke, senior product manager at Google Workspace, told CSO. \u201cOrganizations resolve these issues either through incredibly intricate and expensive IT management or by minimizing communications with entities outside their company. Neither is a satisfactory option.\u201d<\/p>\n

Google creates new email encryption model<\/h2>\n

Google took a different approach and created a new model that no longer requires complex user certificate management or exchanging keys with external organizations to decrypt messages.<\/p>\n

Google\u2019s new E2EE Gmail implementation<\/a> relies on the existing client-side encryption (CSE) feature in Google Workspace<\/a>, which allows customers to use their own encryption keys to encrypt files and emails on the client-side before they are stored on Google\u2019s servers. This feature allows organizations to control the identity provider used to grant access to the encryption keys and the third-party key management service used to store them.<\/p>\n

In its new integration with Gmail, currently available in beta, customers can choose from the regular Gmail message compose web interface if they want to encrypt the message. For now, the feature only works between Gmail users who are members of the same organization, but over the coming weeks, it will be enabled for all Gmail recipients, both enterprise and personal accounts.<\/p>\n

Later this year, when the feature is fully implemented, Workspace users with E2EE enabled will be able to send encrypted messages to any external email users. Instead of the message, recipients will receive a link that, when clicked, will take them to a restricted version of Gmail where they need to authenticate with the organization\u2019s chosen identity provider to view the decrypted message. External users will also be able to reply within the same restricted Gmail interface.<\/p>\n

Restricted view allows for more control<\/h2>\n

By default, Gmail users won\u2019t have to go through this restricted Gmail experience, and emails will automatically decrypt when they arrive in their inbox if they are the intended recipients. However, administrators can choose to enforce the restricted Gmail view for everyone, including Gmail users, to ensure sensitive communications are not downloaded locally on third-party servers or devices.<\/p>\n

Because this option requires authentication with an approved account and identity provider, organizations can easily revoke access and apply additional security policies. Google describes this experience as similar to a shared document stored in Google Drive.<\/p>\n

\u201cAt a structural level, this approach offers more comprehensive encryption protection,\u201d Julien Duplant, product manager at Google Workspace, told CSO. \u201cIt doesn\u2019t matter who you send a message to or what email they are using; your message will be encrypted, and you are in sole control. There\u2019s just one set of keys, and you\u2019re the only one who has them.\u201d<\/p>\n\n<\/div>\n<\/div>\n<\/div>\n<\/div>","protected":false},"excerpt":{"rendered":"

Google has introduced a new end-to-end encryption (E2EE) feature in Gmail, enabling organizations to send encrypted emails that even Google cannot read to other Gmail users. Later this year, the feature will be expanded to allow the sending of encrypted emails to any email users, including those from other providers. E2EE differs from encrypting email […]<\/p>\n","protected":false},"author":0,"featured_media":2577,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-2596","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-education"],"_links":{"self":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/2596"}],"collection":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=2596"}],"version-history":[{"count":0,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/2596\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/media\/2577"}],"wp:attachment":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=2596"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=2596"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=2596"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}