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. 
Higher Education: 15 Books to Help Cybersecurity Pros Be Better
Curtis Franklin Jr., Senior Editor at Dark Reading,  12/12/2018
Worst Password Blunders of 2018 Hit Organizations East and West
Curtis Franklin Jr., Senior Editor at Dark Reading,  12/12/2018
2019 Attacker Playbook
Ericka Chickowski, Contributing Writer, Dark Reading,  12/14/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
10 Best Practices That Could Reshape Your IT Security Department
This Dark Reading Tech Digest, explores ten best practices that could reshape IT security departments.
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.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2017-1265
PUBLISHED: 2018-12-17
IBM Security Guardium 10.0, 10.0.1, 10.1, 10.1.2, 10.1.3, 10.1.4, and 10.5 does not validate, or incorrectly validates, a certificate. This weakness might allow an attacker to spoof a trusted entity by using a man-in-the-middle (MITM) techniques. IBM X-Force ID: 124740.
CVE-2017-1272
PUBLISHED: 2018-12-17
IBM Security Guardium 10.0 and 10.5 stores sensitive information in URL parameters. This may lead to information disclosure if unauthorized parties have access to the URLs via server logs, referrer header or browser history. IBM X-Force ID: 124747. IBM X-Force ID: 124747.
CVE-2017-1597
PUBLISHED: 2018-12-17
IBM Security Guardium 10.0, 10.0.1, 10.1, 10.1.2, 10.1.3, 10.1.4, and 10.5 Database Activity Monitor does not require that users should have strong passwords by default, which makes it easier for attackers to compromise user accounts. IBM X-Force ID: 132610.
CVE-2018-1889
PUBLISHED: 2018-12-17
IBM Security Guardium 10.0 and 10.5 is vulnerable to cross-site scripting. This vulnerability allows users to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session. IBM X-Force ID: 152080.
CVE-2018-1891
PUBLISHED: 2018-12-17
IBM Security Guardium 10 and 10.5 is vulnerable to cross-site scripting. This vulnerability allows users to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session. IBM X-Force ID: 152082.