Endpoint // Privacy
2/27/2017
04:25 PM
Connect Directly
Twitter
Twitter
RSS
E-Mail
50%
50%

Google's Ease-of-Use Email Encryption Project Goes Open Source

E2Email, together with open source Key Transparency project, are meant to take on the challenges that have dogged end-to-end email encryption adoption for decades.

Engineers at Google for several  years have been doing battle against the perception that end-to-end email encryption necessarily must be complex and hard to use. They've been cooking up a project called E2EMail that's designed to offer a simpler alternative to PGP for Gmail through a Chrome Extension, and now they're taking the project to the open-source community.

Google's internal security team at the firm released the extension over a year ago, and hope that going open source will advance the project and easy-to-use email encryption.

"E2EMail is built on a proven, open source Javascript crypto library developed at Google," wrote KB Sriram, Eduardo Vela Nava, and Stephan Somogyi of Google's security and privacy engineering team in an announcement on Friday. "It’s now a fully community-driven open source project, to which passionate security engineers from across the industry have already contributed." 

According to the engineers, Google initiated the project because PGP in command-line form "clumsily interoperates with Gmail" and is "too hard to use."

E2Email integrates OpenPGP in a simpler-to-use extension that keeps cleartext of the message exclusively on the client. This announcement follows close on the heels of another made last month about another open source initiative called Key Transparency, which Google believes fits hand-in-glove with E2Email.

The Google security team kicked off the Key Transparency project to tackle the challenges of discovery and distribution in OpenPGP implementations. The goal is to create an open-source and transparent directory of public keys with an ecosystem of mutually auditing directories.

"We’ve spent a lot of time working through the intricacies of making encrypted apps easy to use and in the process, realized that a generic, secure way to discover a recipient's public keys for addressing messages correctly is important," wrote Ryan Hurst and Gary Belven of Google's security and privacy team last month. "Not only would such a thing be beneficial across many applications, but nothing like this exists as a generic technology."

They explain that the manual verification required by the PGP web-of-trust model has proven over the last 20 years to be too difficult to gain widespread use. They believe that the relationships between online personas and public keys need to be automatically verifiable and publicly auditable, and that's what the Key Transparency project intends to strive for.

When it comes to email encryption, the Google security team believes that Key Transparency is "crucial" to E2Email's evolution and that's where it hopes to lead the open source efforts in the near future. Google's encouraging community participation by directing interested contributors to the E2Email repository on GitHub.

Related Content:

Ericka Chickowski specializes in coverage of information technology and business innovation. She has focused on information security for the better part of a decade and regularly writes about the security industry as a contributor to Dark Reading.  View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
macker490
50%
50%
macker490,
User Rank: Ninja
2/28/2017 | 6:33:22 AM
authentication
the key to the proper use of Public Key Encryption -- lies in understanding authentication

I could send you my public key.   or you can download it from the keyservers.   key ID: 4DEA0DAD

but how would you assure yourself that you have it correct?

it's not all that hard: you need an "introducer".    this could be just a phone call or a private meeting.   or it can be done using a trusted service

this is where things get hung up though.   and it's not the fault of the public; it's the fault of the software industry -- which has not moved forward with authentication and privacy -- even though the need is critical.    Tax returns -- Forms 1040 -- would be a first rate example.

as well as "phishing" type e/mails -- which have been a principle vector for malware.     all messages should be authenticated -- so that users can drop unwanted inputs.    unfortunately there's grifters about who are very much against the idea of bringing communication under control

for the record -- Public Key Incryption -- GPG/PGP -- has been available in e/mail -- incorporated into products such as Thunderbird/ENIGMAIL -- for a good many years now.    Echelon and CLAWS also incorporate GPG; too you can incorporate Symantec PGP/Desktop into MSFT/Outlook.

so what Google wants to do here isn't new.   it's Past Due.
Richard_ABT
50%
50%
Richard_ABT,
User Rank: Author
2/28/2017 | 12:23:54 AM
Will it be enough?
I've been trying to get friends and family to encrypt messages for years - with little to no success. Will this be enough to get people to start? I'm hopeful, but doubtful. I think it's going to fall upon all of us to make it even more seamless and invisible to the 'regular' end user. 
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
Security Operations and IT Operations: Finding the Path to Collaboration
A wide gulf has emerged between SOC and NOC teams that's keeping both of them from assuring the confidentiality, integrity, and availability of IT systems. Here's how experts think it should be bridged.
Flash Poll
New Best Practices for Secure App Development
New Best Practices for Secure App Development
The transition from DevOps to SecDevOps is combining with the move toward cloud computing to create new challenges - and new opportunities - for the information security team. Download this report, to learn about the new best practices for secure application development.
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2017-0290
Published: 2017-05-09
NScript in mpengine in Microsoft Malware Protection Engine with Engine Version before 1.1.13704.0, as used in Windows Defender and other products, allows remote attackers to execute arbitrary code or cause a denial of service (type confusion and application crash) via crafted JavaScript code within ...

CVE-2016-10369
Published: 2017-05-08
unixsocket.c in lxterminal through 0.3.0 insecurely uses /tmp for a socket file, allowing a local user to cause a denial of service (preventing terminal launch), or possibly have other impact (bypassing terminal access control).

CVE-2016-8202
Published: 2017-05-08
A privilege escalation vulnerability in Brocade Fibre Channel SAN products running Brocade Fabric OS (FOS) releases earlier than v7.4.1d and v8.0.1b could allow an authenticated attacker to elevate the privileges of user accounts accessing the system via command line interface. With affected version...

CVE-2016-8209
Published: 2017-05-08
Improper checks for unusual or exceptional conditions in Brocade NetIron 05.8.00 and later releases up to and including 06.1.00, when the Management Module is continuously scanned on port 22, may allow attackers to cause a denial of service (crash and reload) of the management module.

CVE-2017-0890
Published: 2017-05-08
Nextcloud Server before 11.0.3 is vulnerable to an inadequate escaping leading to a XSS vulnerability in the search module. To be exploitable a user has to write or paste malicious content into the search dialogue.

Dark Reading Radio
Archived Dark Reading Radio
In past years, security researchers have discovered ways to hack cars, medical devices, automated teller machines, and many other targets. Dark Reading Executive Editor Kelly Jackson Higgins hosts researcher Samy Kamkar and Levi Gundert, vice president of threat intelligence at Recorded Future, to discuss some of 2016's most unusual and creative hacks by white hats, and what these new vulnerabilities might mean for the coming year.